Countdown timer GIF not updating? Causes and fixes

When a countdown timer GIF is not updating, the cause is nearly always a copy of the image, not the timer itself: Apple Mail loaded it before the email was opened, a proxy or browser reused an old copy, or classic Outlook is showing only the first frame. Testing habits cause the rest, especially with evergreen timers that remember each recipient's first open.

Each cause leaves a different fingerprint. Work out which one you're looking at, and the fix is usually a setting or a habit, not a new tool.

How a live countdown GIF is supposed to update

A live email countdown is an animated GIF that a server draws at the moment it's requested. Frame one shows the time left right now, each following frame is one second later, and the GIF holds a fixed number of frames before it loops. flashtimer's timers hold 60 one-second frames, so about a minute of countdown.

That means a timer updates in exactly one way: the email client asks the server for the image again. Every "not updating" problem comes down to something answering that request with an old copy, or the request never happening. Here are the usual suspects, most common first.

Cause 1: Apple Mail Privacy Protection loaded the timer early

Fingerprint: readers on iPhone, iPad or Mac Mail see more time left than they should, sometimes hours more, or an evergreen timer that has already counted down before they opened the email.

Apple's Mail Privacy Protection fetches images through Apple's servers when an email arrives, not when it's read. Apple's own Mail Privacy Protection privacy page says it "downloads remote content in the background by default" and does so "regardless of whether you engage with the email." Apple Mail can then show that early copy when the reader finally opens the message.

Klaviyo's help center describes the result plainly in its countdown timer article: Apple Mail "generally pre-loads emails before they are opened, which can cause a countdown timer to display an incorrect time." Litmus notes the same problem for all time-sensitive images: by the time the recipient opens the email, a cached image may no longer be relevant.

How to fix it

Put the deadline in text. "Ends Friday at midnight ET" is correct whether the timer is fresh or stale.
Give Apple's early fetch something that can't go stale. In flashtimer (Pro and up), the timer editor's Apple Mail setting chooses what Apple's privacy fetch gets instead of the live countdown: Live countdown, A fixed message (your own short line in the timer's styling, such as "Ends Friday at midnight ET"), The fallback image you uploaded, or Nothing (hide the timer). Readers in other clients still get the live countdown. Once the deadline has passed, Apple gets the normal expired image, which is correct whenever it's shown.
Evergreen timers: with Live countdown selected, Apple's fetch at delivery counts as the reader's first open, so their personal countdown starts before they've seen the email. Choosing any other Apple Mail option avoids that, because the substitute is served without starting the countdown.

Cause 2: Gmail's image proxy or the browser reused a copy

Fingerprint: in Gmail, reopening the email shows the same time as last time, or the timer looks right on first open but not on later ones.

Gmail doesn't fetch images straight from your server. It loads them through Google's own image proxy, which is why, as Gmail Help puts it, senders can't use image loading to learn about your computer or location. Word to the Wise covered the switch when Google rolled it out. A proxy is a cache, and a cache will happily serve an old countdown if the image server doesn't tell it not to.

How to fix it

Use a timer service that sends no-cache headers. flashtimer serves every live countdown with Cache-Control: no-store, no-cache, must-revalidate, max-age=0, plus Pragma: no-cache and Expires: 0 for older caches. That tells Gmail's proxy and any browser cache to fetch a fresh image on each open instead of reusing one.
When you test, reload the page. A browser tab that already has the image in memory may show it again if you click back into the same email. Refresh Gmail or open the email in a new tab before you decide the timer is stuck.
Don't host a timer screenshot. If the image in your sent email lives on your platform's file library instead of the timer service's URL, it will never update. See cause 5.

Cause 3: classic Outlook is showing only the first frame

Fingerprint: the timer shows a correct time but never ticks, only in Outlook for Windows.

Classic Outlook for Windows renders email with Microsoft Word, which shows only the first frame of a GIF. The frame is accurate at the moment of opening; it just doesn't move. This isn't a caching problem and no header can change it. The details, version by version, are in why a countdown timer isn't working in Outlook.

Cause 4: your evergreen timer remembers your first open

Fingerprint: you test an evergreen timer, and each new test shows less time than the last, or zero, or your expiry message.

An evergreen countdown timer gives each recipient their own deadline, counted from their first open. To do that it needs to recognise the recipient, so the image URL carries your email platform's per-recipient merge tag, for example ?vid={{ person.KlaviyoID }} in Klaviyo or ?vid=*|UNIQID|* in Mailchimp. The first time a given recipient's image is requested, flashtimer records the moment (it stores a hash of the value, not the value itself). Every later open reuses that start time. That's the whole point: reopening the email must not restart the countdown.

It also means that once you've opened a test as yourself, your countdown is running. Test again tomorrow and you'll see a day less, which looks exactly like a timer that isn't updating properly.

How to fix it

Test with a fresh contact. Use a new test profile or an address alias (such as you+test7@yourdomain.com where your mail provider supports it) for every round of evergreen testing.
Use the editor preview for design checks. flashtimer's own previews show a fresh countdown and never start anyone's clock.
Check that the merge tag is filled in. If the platform sends the URL without a per-recipient value, every such open shares one countdown that starts at the first of them, so later readers see less time. The embed snippet adds your platform's merge tag where it has one (the embed dialog says when it doesn't); if you built the URL by hand, compare it with the snippet.
Expect the editor preview in your email platform to look odd. Inside the platform's editor the merge tag isn't filled in yet, so every editor preview counts as the same "recipient". That doesn't affect real recipients.

Cause 5: the email platform copied or cached the image

Fingerprint: the timer never changes for anyone, in any client, and it showed the same time in your test as it does now.

Some editors offer to upload or import an image from a URL into their file library. If that happens, your email no longer points to the timer service at all; it points to a static snapshot taken when you built the email. Platform preview panes can also cache an image while you edit.

How to fix it

Link, don't upload. Paste the timer's image URL into an image block's URL field, or paste the HTML snippet into an HTML or code block. Don't download the GIF and upload it.
Check the sent email. Open a real test email, right-click the timer (or long-press it on mobile) and copy the image address. It should still point to the timer service. Note that in Gmail you'll see a googleusercontent.com proxy address instead; check in another client.
Judge the timer in a real inbox, not the editor preview. Send a test and open it twice a few minutes apart.

Cause 6: the GIF looped back

Fingerprint: you've had the email open for more than a minute and the timer jumps back up.

GIF timers contain a fixed number of frames. A flashtimer GIF holds 60 seconds of countdown and then loops, so if someone leaves the email on screen for five minutes, the clock replays the same minute. Closing and reopening the email requests a fresh image with the current time. This is how every animated-GIF timer works, and it's rarely noticed by readers, who glance at the email rather than watch it.

Other things that look like "not updating"

The timer has ended. After the deadline the image shows your expiry message or fallback image. If that appears early, check the end date and the timer's time zone.
The wrong time zone. A timer set to 11:59 pm in the wrong zone is "correct" and still hours off. Fixed timers count down to one moment for everyone; check which zone that moment is in.
You've hit your plan's view allowance. On every plan, timers switch to a static image once views pass the monthly allowance, plus any top-up credit, by 4%. Check your usage on the dashboard, and see pricing for each plan's monthly views.

A quick testing checklist

Send a real test to Gmail, Apple Mail and, if your readers use it, classic Outlook. Don't rely on the platform's preview pane.
Open the test, note the time, close it, wait two minutes, open it again. The time should have moved on by two minutes.
For evergreen timers, use a contact who has never opened this timer before.
Copy the image address from the received email and confirm it still points to the timer service.
Confirm the deadline appears in text near the timer, and that the alt text states it too.

FAQ

Why does my countdown timer show the wrong time on iPhone?

Apple Mail Privacy Protection downloads images when the email arrives, before the reader opens it, and Apple Mail may show that early copy. The timer then shows the time left at delivery. State the deadline in text, and if your timer tool offers it, give Apple Mail a fixed message or fallback image instead of the live countdown.

Does Gmail cache countdown timer GIFs?

Gmail loads every image through Google's image proxy, which can cache it. A timer served with no-cache headers, as flashtimer's are, tells the proxy to fetch a fresh copy on each open. If you're testing in a browser, refresh Gmail before reopening the email, since the open tab may still hold the image it already loaded.

Why does my evergreen countdown timer show zero when I test it?

Evergreen timers start each recipient's countdown at their first open and remember it, so reopening doesn't reset the clock. If you've opened a test as yourself before, your countdown kept running and may have ended. Test with a contact who has never opened that timer, and use the editor preview for design checks.

How long does an email countdown GIF animate?

Usually about a minute. A GIF timer holds a fixed set of frames, one per second, then loops. flashtimer's timers hold 60 frames. Readers rarely notice, because a new image with the current time is fetched every time the email is opened again.

Can I force a countdown timer to refresh?

You can't push an update into an email that's already open. The timer refreshes each time the email client requests the image again: when the reader reopens the email, or reloads the page in webmail. That's why the timer service's cache headers matter, and why your deadline should also be written in the email.

Why is my countdown timer frozen in Outlook but fine elsewhere?

Classic Outlook for Windows uses Microsoft Word to render email and shows only the first frame of an animated GIF. The frame shows the correct time left when the email was opened, but it doesn't tick. Newer Outlook apps, including the new Outlook for Windows and Outlook on the web, play the animation.

Use a timer built for these edge cases

flashtimer serves every live countdown with no-cache headers, lets you give Apple Mail's early fetch a version that's never stale on Pro, and remembers each evergreen recipient's first open so reopening never restarts the clock. Start free — no card.