- Size the video to the task: time the real actions at a readable pace, add a short result-first hook, and split only when the outcome changes.
- Read the retention curve for cliffs rather than averages, because a sharp drop at one timestamp points to one scene to fix.
- Never hit a length target by speeding up playback or cutting explanation; remove repeated steps and dead waiting time instead.
Most advice on tutorial video length starts with a number: keep it under three minutes, or five, or as short as you can. Those numbers are averages across other people’s videos, and averages hide the thing that actually decides length. A tutorial should run as long as the viewer’s task takes once they’re paying attention, plus whatever it costs to get them started. A two-minute video is far too long if the task takes twenty seconds. A twelve-minute video can be exactly right if it walks someone through a complete setup they would otherwise never finish.
So the useful question isn’t “how long is too long?” It’s “how much of this video is the thing the viewer came for?”
Tutorial video length starts with the task
A tutorial is a stand-in for practice. The viewer watches so they can do the thing afterward, and every second of the video either moves them toward doing it or gets in the way. That gives you a floor you can calculate before you record anything.
Count the actions the viewer must perform, and time each one at a pace you’d want them to see it. A click plus a short pause to register what changed is usually a few seconds. Typing a value adds time in proportion to its length. Then add the things the viewer needs to understand the action, such as the one warning that changes what they do next.
Take a tutorial on connecting a custom domain to a project. The steps are: open settings, choose the domain section, enter the domain, copy the two DNS records shown, switch to the registrar, paste them in, return and confirm. That’s seven actions. At roughly seven seconds each, counting the pause to register, the action alone runs close to fifty seconds. Add a fifteen-second opening that shows the finished domain with its green status, and twenty seconds to explain the one non-obvious point: DNS changes can take anywhere from minutes to a day or more to spread, so the status may stay pending for a while. The honest length is about ninety seconds.
If your draft runs six minutes, the extra time isn’t explanation. It’s padding, or a rehearsal of things the viewer already knows, or a wait that nobody cut. That’s the diagnosis you need before you start trimming.
These ranges are a starting point, not a benchmark. Adjust them once you have retention data for your own audience.
| Task type | Typical shape | Working length |
|---|---|---|
| One setting change | A single action with a result | 30 to 60 seconds |
| Five to eight step task | A sequence with one decision | 1.5 to 3 minutes |
| Full workflow | Several decisions and branches | 5 to 8 minutes, chaptered |
| Feature overview for onboarding | One feature’s value, shown briefly | 60 to 90 seconds |
Why the first seconds decide more than the last minute
Viewers make their decision about a tutorial early. In the first seconds they’re asking whether this video answers their question and whether it’s worth the time it asks for. A long setup, a logo animation or a slow greeting spends the commitment the viewer hasn’t yet given you.
A steep drop in the first thirty seconds is normal, and you can’t fully prevent it. Some of the people who click are not the people you made the video for. What you can control is whether the first ten seconds show the result. Open on the finished state, whether that’s a published page, a sent message or a working integration, then say what you’re going to do and how long it will take. The viewer now knows the cost and the payoff, and most of the remaining decision is made.
Keep the opening to a sentence or two of narration. Cut the setup entirely. Nobody needs to watch you find the right browser tab or log in. Start recording once you’re already at the point where the work begins.
Hold each result long enough to register
A state change on screen is information, and the viewer needs a moment to take it in. When a toast message appears, a toggle flips, or a status moves from pending to active, the eye has to find the change, read it, and connect it to the action that caused it. If your next click lands half a second later, the viewer is still reading the first change when the second one starts, and the lesson gets lost in the transition.
The practical rule is to hold each meaningful result for one to two seconds before the next action. That feels slow while you’re recording, because you already know what happened. It doesn’t feel slow to the viewer, who is still catching up. Holds cost very little running time, and they are what separates a video a viewer can follow from one they can only watch.
Be selective. Hold the results that matter to the outcome: the moment a domain turns green, the message that confirms a send. Don’t hold trivial ones, like a menu opening before you click an item in it. A useful test is to ask whether the viewer has to see the new state to believe the next step. If they do, hold. If the next step makes sense without it, cut straight to the action.
Holds also make narration easier. A pause of a second or two after a result gives the narrator a natural place to say what happened, so the viewer hears the explanation while looking at the change it describes. Without the hold, the narrator talks over the next action, and the words and the screen compete for the same attention.
Read the retention curve for cliffs, not averages
Every serious video platform shows an audience retention curve, the share of viewers still watching at each second. YouTube Studio has one in its analytics, and the share-page analytics in RecordlyPro show where viewers drop as well. Most people look at the average view duration, which is a single number that tells you almost nothing about what to change.
Read the curve’s shape. A smooth decline means viewers are leaving at a steady rate, which is what a normal video looks like. A cliff means something specific happened at one second: an unexplained wait, a click the viewer couldn’t find, an explanation they’d already heard, or a segment that didn’t match the title. Some platforms also show a bump where viewers replay a section, and that bump is worth investigating in the same way.
Here’s an illustrative example, with made-up numbers. Out of 1,000 viewers, 620 are still watching at 0:30, which is a normal start. At 3:00, 480 remain. By 3:20, only 310 are left, and the curve is flat after that. The cliff sits in a twenty-second window. Watch the seconds around 3:05 and you find the narrator saying “the sync status will update,” while the screen shows a loading spinner for fourteen seconds. The fix is to cut the spinner, or the narration over it, not to shorten the whole video. A loss of 170 viewers in one spot is a specific, fixable problem. An average view duration of 2:40 is not.
One caution: a cliff only tells you where people left. It doesn’t tell you why. Before you rewrite a scene, watch the seconds before the drop and ask what the viewer was looking at. That’s where the answer usually is.
Split when the outcome changes, not when the clock does
Sometimes a tutorial is too long because it’s teaching two things. “Set up your workspace and invite a teammate” is two outcomes. A viewer who came for the invitation pays for the workspace setup first, and some of them leave before they reach the part they wanted.
The test is simple. Write the sentence “by the end of this video, the viewer can ___.” If you need two blanks, you need two videos, each with one outcome, linked to each other. If you need one blank but the video has several chapters, a chapter list will do the job, and you can leave the video whole.
Splitting by the clock is the mistake to avoid. Cutting a ten-minute video into five-minute halves just because ten minutes felt too long produces two videos that each start in the middle of something. Split on the seam where the viewer’s goal changes, and each piece will stand on its own.
Watch out: playing a tutorial at 1.5 times speed to hit a length target costs more than it saves. Viewers can't read a settings label or register a button state at that pace, and the pauses that signal "this matters" disappear.
A worked cut: from nine minutes to under four
Here’s a realistic draft of a tutorial called “Set up automations.” It runs nine minutes. The intro is ninety seconds of company background. Explaining what an automation is takes two minutes. The build takes two minutes, and the example is the same one as the next step. Rebuilding a trigger the viewer has already watched takes ninety seconds. A thirty-second wait for a test run is still on screen. The test itself runs ninety seconds.
The edit goes like this. The intro shrinks to ten seconds of the finished automation firing. The concept section moves to a linked article, because the viewer who needs it can read it in two minutes and the viewer who doesn’t can skip it. The build stays, since it’s the core of the outcome. The repeated trigger is cut entirely, because the viewer saw it once. The thirty-second wait becomes a three-second cut with a short narration beat over it. The test stays, because it proves the result. The finished video runs three minutes and forty-three seconds, and the viewer gets the same outcome.
The chart below shows the same tutorial before and after. Solid segments are the parts that still earn their time.
Notice what didn’t get cut. The build and the test are the outcome. Everything removed was either a repeat, a wait, or information that belongs somewhere else. That’s the pattern in almost every tutorial that goes from long to tight: the cuts are subtraction, not compression.
Measure the silent version: time your draft's action segments with the narration muted. If the silent actions alone run longer than the outcome deserves, no amount of narration editing will fix the pacing.
When a long tutorial is the right tutorial
Some tutorials really do need eight minutes. A full data import with mapping, validation and a fix for one common error has several decisions in it, and each decision needs a moment of attention. In that case, length isn’t the problem. The problem is navigation. A long video without an index forces the viewer to scrub for the step they need, and most will give up before they find it.
This is where chapters earn their place. Give each decision its own chapter, title it with the question the viewer is asking at that moment, and let the viewer jump straight to the part that matters to them. A viewer who comes back a week later to finish the import knows exactly where to resume.
The length of a tutorial, then, is governed by two things. Its outcome sets the minimum, and its structure determines whether the viewer can use a longer video at all. Work on both before you reach for the scissors.
Pacing the narration against the clicks
Most tutorial narration is paced too fast, and the usual symptom is a sentence that finishes after the click it describes. The narrator planned to say “open the menu and pick Export” as the cursor moves, and by the time the sentence ends, the viewer is already on the next step. The fix is to match the narration to the duration of the action, not to the amount of information in it.
A simple check is to record the silent action first, then narrate once over the playback and time it. If a sentence takes four seconds to say and the action it describes takes two, you have two options. Shorten the sentence, or slow the action down with a zoom or a hold. Speeding up the video makes the problem worse, because the narration then sounds rushed over footage that’s already fast.
Watch for the opposite problem too. A narrator who leaves long silences during a slow stretch makes the video feel like it’s waiting. Where nothing changes on screen, a sentence of explanation fills the time usefully. Where the screen is busy, the narration should be brief. Balancing those two is most of what editing a tutorial really involves.
Where to go from here
Most tutorials that feel too long are carrying weight the viewer never asked for: a company intro, a concept they already know, a repeated step, a wait that nobody trimmed. Find those first. Then check whether the outcome needs one video or two, and whether a long one needs chapters to be usable.
If you’re recording the walkthrough in your browser, keeping each click readable matters more than you’d expect. RecordlyPro zooms the frame onto each click as you record, which keeps a short tutorial clear enough that you don’t need to pad it with explanation. After you publish, the share page shows where viewers drop, so the next edit is based on a cliff you can see rather than a feeling about length. For the start of that process, how to record a software tutorial people actually finish covers the scripting side in more detail.
Keep reading
Async video: stop scheduling the meeting you could record
A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.
Sofia Meyer
October 6, 20262 min readAuto-zoom in screen recordings: what it is and why your demos need it
A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.
Sofia Meyer
October 13, 20262 min readHow to choose a screen recorder for product demos in 2026
A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.
Sofia Meyer
October 16, 20262 min readDofollow vs nofollow in 2026: what still passes value
The link attributes changed, Google's treatment changed, and a lot of advice is out of date. Here's what dofollow, nofollow, sponsored and ugc actually do now.
The Recordly Team
October 10, 20262 min read