How to Make a Timer in Scratch: Two Ways That Work

Most tutorials teach the wrong one first. If you want a timer in Scratch, Scratch already has one: a block called timer sitting in the Sensing category, which reports how many seconds have passed and never drifts. The popular approach of counting seconds with a wait 1 seconds loop is less accurate, and it is the one most guides lead with.

Both have a place. The built-in block is right when you want to know how long something took. A counting variable is right when you want a number that goes down, which is what a countdown needs. This tutorial covers both, says which to reach for, and explains the drift problem so your child understands why rather than just copying blocks.

What a timer does in a Scratch project

Two jobs, and they are worth separating before building anything. Measuring elapsed time answers "how long did the player take", which is how you build a best-time score. Limiting time answers "you have 30 seconds left", which is how you build pressure into a game.

The first job wants the Sensing block. The second wants a variable. Picking the wrong one is why timers so often misbehave in children's projects.

Method 1: the built-in timer block, in three blocks

Scratch's timer block reports the time since the project loaded or since the timer was last reset, measured in seconds. It starts running by itself, so the only thing you have to do is decide when zero is.

1. Drag in when green flag clicked from the Events category.
2. Add reset timer from Sensing. This is the block that makes zero mean the start of your game rather than the moment the page loaded.
3. Tick the checkbox next to the timer block in the Sensing palette. The value appears on the stage.

That is a working, accurate timer. Three blocks, no variables, no loop.

One rough edge worth knowing: the stage display for timer shows tenths of a second, so it reads 12.4 rather than 12. In a game that looks untidy. The fix is to round it into your own variable:

1. Make a variable called Time Passed through Variables, then "Make a Variable", and choose "For all sprites".
2. Add a forever loop from Control, under the reset timer block.
3. Inside it, put set Time Passed to (round (timer)), taking round from Operators and timer from Sensing.
4. Untick timer and tick Time Passed instead.

Now the stage shows whole seconds, and the number underneath is still the accurate system clock rather than a count.

Why the counting method drifts, and why that is worth teaching

The familiar approach looks like this: set a variable to 0, then forever, wait 1 seconds, change Timer by 1. It works, roughly, and it is a good first use of a variable. It is also slightly wrong in a way children find genuinely interesting once they see it.

The loop waits one second, then runs the change block, then goes back to the top. The wait is one second. Everything else costs a little more. So each pass round the loop takes marginally longer than a second, and the error adds up rather than cancelling out. Over a short game it hardly shows. Over three minutes a counted timer can sit several seconds behind the real clock.

Here is the experiment worth doing with a child, because it takes two minutes and settles the point better than any explanation. Build both on the same sprite: the counting variable and a rounded timer side by side on the stage. Run the project and leave it for a minute or two. Watch the two numbers separate.

That is a real measurement, and it teaches something more durable than the tutorial does: the code that looks obviously correct can be quietly inaccurate, and the way you find out is by checking it against something you trust. Reading what your program actually does rather than what you meant it to do is the habit underneath all debugging, and it is the same skill we build in teaching kids to debug.

Method 2: a countdown timer, where a variable is the right tool

For a countdown you genuinely need a variable, because you need a number that decreases and that the player can see. The Sensing block only counts up.

1. Make a variable called Time Left, for all sprites.
2. Under when green flag clicked, add set Time Left to 30, or whatever your limit is.
3. Add repeat until <Time Left = 0> from Control, rather than a forever loop. Using repeat until means the loop ends by itself instead of running on past zero into negative numbers, which is the commonest bug in countdown projects.
4. Inside the loop, put wait 1 seconds then change Time Left by -1. The minus sign is the whole trick, and it is easy to miss.
5. After the loop, add what should happen when time runs out: broadcast game over, or say "Time up", or stop all.
6. Tick Time Left to show it on the stage.

The drift applies here too, so a 30-second countdown may take a little over 30 real seconds. For a game that does not matter: what matters is that the player gets the same amount of time every run, and they do.

Stopping a timer, which is not quite what it sounds like

You cannot stop the Sensing timer. It runs as long as the project is open, by design. What you stop is reading it.

The usual pattern uses a boolean variable as a switch. Make a variable called game over and set it to 0 when the green flag is clicked. Replace the forever loop with repeat until <game over = 1>, still updating Time Passed inside it. When something in your game sets game over to 1, the loop finishes and the display freezes at the final value, which is exactly what you want for a results screen.

This is also where children meet a genuinely useful idea: a variable does not have to hold a quantity. It can hold a yes or no that other scripts check.

Which one should your child use?

That last row is the honest caveat to everything above. If the point of the session is learning what a variable is, the counting method is the better lesson even though it is the worse timer. Build it, then break it with the side-by-side experiment, then show the Sensing block as the fix. That sequence teaches more than starting with the right answer.

Where to take it next

A timer is rarely the project. It is the piece that makes a project feel like a game, which is why it is worth getting right early. Once it works, the obvious next steps are a score variable alongside it, then a results screen that shows both.

If your child is ready for a full project rather than a component, how to make a game on Scratch puts the pieces together, and seven Scratch games to play and remake is the better route for a child who learns by taking things apart. For where this sits in a longer progression, the Scratch curriculum progression guide maps it out, and Scratch projects by age group helps pitch the next one correctly.

Our Scratch classes work from projects a child wants to build rather than a block checklist, which is usually the difference between a timer that gets built and a timer that gets understood.