Why your timer stops after a minute

Every animated countdown in email stops. A GIF is a finite list of pictures, and at one picture per second a minute of motion costs sixty pictures of bytes, so every vendor sets a ceiling. The documented ones run from 45 to 90 seconds. They sit in help-centre articles rather than on pricing pages, and they differ enough to change which resolution you should pick.

The documented ceilings

Four vendors, four different numbers, and not one of those figures appears on the page where a marketer decides what to buy.

Why the ceiling exists

Drawn the naive way, a 600 by 200 countdown with sixty seconds of motion is sixty pictures of a 600 by 200 canvas. The file gets heavy enough to matter on a mobile connection, and heavy enough to shift the text-to-image ratio that some spam filters look at.

There are two ways to buy more seconds for the same bytes, and both are decisions a renderer makes rather than settings you choose.

The first is sub-rectangle encoding. Only the digits change between one second and the next, so only the rectangle containing the digits needs to be redrawn. EmailTimer.App emits frame one as a full-canvas image and every subsequent frame as a small rectangle over the digit strip. Disposal is set to leave the previous frame in place, so the unchanged rest of the canvas simply persists. A second of animation costs a strip, not a canvas.

The second is a fixed palette. Every animated frame here draws from one global colour table, so no frame carries a table of its own and no quantiser runs at request time. Frame one carries a local table whose first entries are that same palette in the same order. That is what lets the digit sprites be copied into frame one without remapping, and keeps frame one’s digits pixel-identical to frame two’s. Without that prefix trick the two can disagree by one shade and you see a visible flick on the first tick.

Those two decisions are why 30 frames at 600 by 200 stays under 400 KB with room to spare, and they are the difference between a 45-second ceiling and a comfortable one.

The resolution trap

The ceiling only hurts when the resolution and the horizon disagree.

A timer showing seconds on a three-day countdown is displaying a digit that changes every second for a value that is meaningless at that precision. Sixty frames later, the seconds column stops, and the recipient watching it concludes the timer is broken. Customer.io documents this exact outcome for its own block: set the resolution to seconds and “the counter will stop 60 seconds after the image loads”.

A timer showing hours and minutes on the same three-day countdown is correct for the whole animation, and its minutes column changes at most once in it. If that GIF stops, its last frame stays right until the next minute turns. If it loops, as every EmailTimer.App timer does, each pass goes back by one minute at most, and often not at all.

Show the smallest unit that will actually change during the animation, and no smaller.

When the frames run out

Two vendors above make different choices at the end of the frames, and the difference matters more than the frame count.

MailerLite loops at 90 seconds. MotionMail stops, then restarts on every re-open. A looping timer returns to its first frame when it finishes, which means it shows a number from the start of the animation again, as if it were current. Watch one for three minutes and you will see the same number three times. A timer that stops leaves its last frame on screen, which is right until its smallest unit next changes and falls behind from then on.

Every EmailTimer.App timer loops, and there is no setting that makes one stop. The seconds keep moving for as long as the message is open, and each pass goes back to the numbers the image was drawn with. Two things keep that honest. Match the smallest unit to the horizon, so a days and hours timer has almost nothing to go back from. And write the deadline in the email as text, where it never goes stale.

Frame one matters whichever way the animation ends. In classic Outlook on Windows, animation depends on a setting outside Outlook, and Microsoft’s own support page says that when it is off, “only the first frame of the animation appears”. A design that depends on the animation is a design that never runs for those readers at all.

What to do about it

1. Match the unit to the horizon. Days and hours for a week, hours and minutes for a few days, minutes and seconds only for the last hour of a sale.
2. Look up your current vendor’s ceiling before your next send. It is in the help centre, not on the feature page. If you cannot find it in ten minutes, that is an answer about the vendor.
3. Ask what happens when the frames run out. A looping timer goes back to an older number on each pass, and one that stops is right only until its smallest unit next changes. Neither keeps time after the last frame, which is why the deadline also belongs in the email text.
4. Check the file size the way a recipient meets it. Load the image URL in a browser on a phone on mobile data. Under 400 KB at 600 by 200 is a reasonable target for a 30-frame timer.
5. Keep the canvas honest. A 600 by 200 timer at a sensible frame count is a small file. A 1200 by 400 retina timer at sixty frames is a different proposition, so if you are serving at 2x, reduce the frame count rather than the quality.
6. Design frame one to stand alone. It is the whole timer for Outlook readers with animations off, and every other reader sees it again at the start of each pass.
7. The ceiling is not the main accuracy problem. A cached render is, and Apple MPP and the shared image cache covers the client where it bites hardest.
8. If you are on Customer.io, know the second half of the cap. The 60-frame limit applies and the native block does not accept extra CSS, which is covered on the Customer.io setup guide.

Questions and answers

Why does my countdown timer stop after 30 or 60 seconds?

Because the GIF has run out of frames. Every vendor caps the frame count to keep the file small, and the documented caps range from 45 to 90 seconds.

Can I get a timer that animates for the whole hour?

Not as a GIF. One frame per second for an hour is 3,600 frames, which is not a sendable email image at any canvas size.

Is a longer animation better?

Rarely. Most recipients look at a message for a few seconds. Frames beyond that are bytes spent on motion nobody watches, and they buy nothing in Outlook where animation is often off.

Does the timer restart if the recipient re-opens the message?

It depends on the vendor and the client. MotionMail documents a restart on re-open, and a client serving a cached copy will replay the same animation from the same old starting number.

What does EmailTimer.App do at the end of the frames?

It loops. The animation starts again from frame one, on every timer, for as long as the message is open, and there is no setting that makes it stop. Match the smallest unit to the horizon so each pass has little to go back from, and put the deadline in the email text. Plans and limits are on features, and the client-by-client picture is on email clients.