Skip to content
Motion Graphics & Animation

How to Get Countdown and Timer Graphics Right

Learn how to choose between rendered, live and embedded countdown graphics, handle time zones, avoid fake urgency and design end states that work.

Tomas Lindqvist Post-Production Lead 29 min read 20 views
How to Get Countdown and Timer Graphics Right

Countdown and timer graphics look like the simplest job in motion design: some numbers get smaller until they reach zero. In practice they are one of the few graphics where the audience can check your work against a clock on their wrist. A launch countdown that ends three minutes early, a webinar timer that shows the wrong hour for half the audience, or a sale timer that quietly restarts when the page is reloaded all do the same damage. They tell viewers that the brand is either careless or trying to manipulate them.

This guide is for marketers, event producers, in-house video teams and business owners who need a countdown for a product launch, a live stream, a webinar, a conference session or a limited offer. It is written as a decision framework. First we define the three realistic ways to build a countdown: a rendered video, a live graphic driven by a real clock, and a countdown embedded in a web page or email. Then we set out the criteria that decide between them, score each option, walk through the pros and cons, and give a recommendation for each common situation.

The short version is that the right build depends less on how the timer looks than on one question: does the number on screen need to match real time? If it does, a pre-rendered file is usually the wrong tool, however good it looks. If it does not, rendered video is cheaper, more reliable and easier to polish. Everything else, from time zones to accessibility to the end state, follows from that choice.

What countdown and timer graphics actually have to do

Before comparing build methods, it helps to be precise about the jobs a countdown is doing. Most briefs ask for "a countdown" when they need several different things, and the build choice depends on which of those jobs matters most.

Create anticipation

The emotional job of a countdown is to build a sense that something is about to happen. That is why pre-show loops, launch teasers and "we go live in" screens exist. For this job, exact accuracy often matters less than rhythm, sound and design. A ten-second countdown that opens a keynote video is a piece of choreography, not a clock.

Communicate a real deadline

The informational job is to tell people exactly when something starts or ends: registration closes, a stream begins, doors open, an offer expires. For this job accuracy is everything, and the time zone has to be stated or localized. A graphic that says "3 days left" without saying when the three days end, and in which zone, fails this job even if it looks beautiful.

Coordinate people in real time

The operational job appears in live production: a timer that tells a presenter how long they have left, a pre-show clock that tells an audience when the stream will begin, a break timer at a conference. These timers must count against a real clock, and someone must be able to adjust them when the schedule slips.

Stay honest

Every countdown also carries an implicit promise: when this reaches zero, something will happen. If nothing happens, if the timer resets, or if the deadline was never real, you have broken that promise in public. The Federal Trade Commission's advertising guidance, available through the Federal Trade Commission, rests on the principle that advertising claims must be truthful and not misleading, and a false deadline is a claim about the offer. Fake urgency is not only a trust problem; it can be a compliance problem.

Once you know which of these jobs your countdown is doing, the build choice becomes much easier. A teaser needs design; a deadline needs accuracy; a live show needs control; all three need honesty.

Five facts shape every decision that follows:

  • Time zones: A countdown must state the zone it counts to, or localize to the viewer.
  • Rendered video: Cannot update to real time once it has been exported.
  • Live graphics: Can count against a real clock and be adjusted on the fly.
  • Accessibility: Moving counters need a pause control or a text alternative.
  • End state: Every countdown needs a designed, tested state for what happens at zero.

The three ways to build a countdown

There are many tools, but only three fundamentally different approaches. Each has a different relationship with real time, and that relationship determines what it can and cannot do.

Option A: Rendered video countdown

A rendered countdown is animated in a tool such as After Effects, Cinema 4D or a video editor and exported as a fixed file: MP4, MOV, ProRes or an animated format for social. The numbers are baked in. A 10-minute pre-show loop is exactly 10 minutes of frames, and it counts correctly only if it starts playing at exactly the right moment and plays without interruption. Rendered countdowns are the default for social teasers, keynote openers, event walk-in loops that an operator starts manually, and any countdown where the number of seconds is part of a choreographed piece.

Option B: Live graphics driven by a clock

A live countdown is generated in real time by a graphics system rather than played back as a file. That system might be a broadcast character generator, a streaming production tool with a clock or timer source, an HTML graphics overlay loaded as a browser source in streaming software, or a real-time engine. Because the number is calculated at every frame from a target time, the countdown stays correct even if the stream starts late, the operator cuts away and back, or the schedule changes. If you want the deeper background on building graphics that render in real time, our guide to real-time motion graphics in game engines covers the engine side in detail.

Option C: Embedded web or email countdown

An embedded countdown lives on a landing page, in an app or in an email. On the web it is usually a small script that compares a fixed target time with the viewer's clock and redraws the numbers. In email, where scripts do not run, it is typically an image generated by a server at the moment the email is opened, so it shows the correct remaining time at the moment of opening but does not keep counting afterward. Embedded countdowns can localize automatically to each viewer's time zone, which neither of the other options can do.

Many real campaigns use more than one option: a rendered teaser for social, an embedded countdown on the registration page and a live clock on the stream itself. The framework below helps you pick the right option for each placement rather than forcing one asset to do every job.

What to do and what to avoid with countdown and timer graphics, side by side
Good practice against the usual mistakes, from the sources listed below.

The criteria that decide between countdown builds

We use seven criteria. Not every criterion matters equally for every project, which is why the scenario recommendations later in this article weight them differently.

  1. Time accuracy. Does the number on screen match real time for every viewer, whenever and however they watch? This is the single most important criterion whenever the countdown communicates a real deadline or start time.
  2. Time zone handling. Can the graphic state one zone clearly, show several, or localize automatically? A countdown with a global audience that names no zone is a support ticket generator.
  3. Visual polish. How much control does the designer have over typography, transitions, 3D, compositing and sound? Rendered video gives the most control, because nothing has to be computed live.
  4. Reliability under pressure. How likely is it to fail in front of an audience? A video file rarely breaks; a live system has more moving parts; a web script depends on the viewer's device and browser.
  5. Accessibility. Can the timer be paused, is there a text equivalent, and does it avoid overwhelming screen reader users? Moving counters need either a pause mechanism or a text alternative.
  6. End-state control. What happens at zero? Can it switch to "We're live", "Registration closed" or a replay link? Can it avoid showing negative numbers or a frozen 00:00:00 for days?
  7. Cost and effort. Design time, development time, operator time during the event, and how much of it can be reused next time.

Most countdown failures are not design failures. They are failures on accuracy, time zones and end states, which are decided at the build stage. Choose the build for the job first, then design within its limits.

Scoring the options side by side

The scorecard below rates each option from 1 (weak) to 5 (strong) against the seven criteria. These scores are our editorial judgment from production experience, not measured data, and a skilled team can move any of them by a point. What matters is the pattern: each option wins clearly on some criteria and loses clearly on others.

CriterionRendered videoLive clock-driven graphicEmbedded web or email
Time accuracy1 (only correct if started at the exact moment)5 (calculated from a real clock)4 (depends on the viewer's device clock)
Time zone handling2 (one zone, stated in the design)3 (one or several zones, editable live)5 (can localize per viewer)
Visual polish5 (full compositing, 3D and sound)3 (limited by real-time rendering)2 (limited by page weight and fonts)
Reliability under pressure5 (a file plays or it does not)3 (more systems, needs rehearsal)3 (varies by browser and email client)
Accessibility2 (needs a separate text version)3 (needs captions or on-air text)4 (can include live text and pause)
End-state control2 (fixed ending, cannot react)5 (operator or logic controls it)4 (script can swap content at zero)
Cost and reuse4 (cheap to make, cheap to version)2 (setup and operator time)3 (development, then reusable)

Read the scorecard by starting with the criteria your project cannot compromise on. If time accuracy is non-negotiable, rendered video drops out of the running for that placement, regardless of its polish score. If the countdown must look cinematic in a social feed, rendered video wins, and you solve accuracy by stating the date and time in text rather than relying on the animation to be right.

Rendered video countdowns: strengths, limits and how to build one well

Rendered countdowns are where most teams start, and for good reason. They are predictable, portable and as polished as the budget allows. Their one hard limit is physics: once a file is exported, it cannot know what time it is. Every good practice for rendered countdowns is about working with that limit rather than pretending it is not there.

Pros

  • Full creative control over typography, 3D, particles, transitions and sound design.
  • Plays identically everywhere, from a social feed to an arena screen.
  • Very low failure risk during a live event: the file either plays or it does not.
  • Easy to version for aspect ratios, languages and dates once the template is built.

Cons

  • Cannot update to real time; accuracy depends entirely on when playback starts.
  • Counts from the start of playback, so a social viewer who watches a day later sees a meaningless number.
  • Shows one fixed time zone at most, so global audiences must convert in their heads.
  • The ending is fixed, so a schedule slip leaves the countdown hitting zero with nothing happening.

Frame rate and the drift you did not expect

A frame-based countdown is only as accurate as its frame math. If a composition runs at 29.97 frames per second but the animator builds the counter as if every 30 frames were a second, the counter drifts: an hour of such a counter runs about 3.6 seconds longer than an hour of real time. Over a two-minute teaser nobody notices; over a one-hour walk-in loop that is supposed to hit zero as the stream begins, it is visible. The fix is to drive the digits from the composition's time in seconds rather than from frame counts, or to work at an integer frame rate such as 25 or 30 when the countdown will be long.

Drive the digits with expressions, not keyframes

In After Effects, the reliable way to build a counter is an expression on the Source Text property of a text layer that calculates the remaining seconds from the layer's time and formats them as minutes and seconds with leading zeros. Hand-keyframing digits invites typos, and a typo on a countdown is instantly visible. Adobe's documentation on expressions and text layers in the Adobe Help Center covers the Source Text property and the time-related expression methods you need. Build the expression once, expose the start duration as a control, and the same composition renders a 10-second, 60-second or 10-minute countdown without rebuilding anything.

Typography that holds still

Numbers change every second, and in most proportional typefaces a 1 is narrower than an 8. The result is a counter that jitters left and right as it counts. Use a typeface with tabular (fixed-width) figures, or turn tabular figures on if the font supports them, and align the counter on a fixed anchor point. Keep the numbers large: a countdown seen on a phone in a social feed may be displayed at a few centimeters across, and thin weights and tight tracking disappear at that size. Separators such as colons should be visually lighter than the digits so the eye reads groups, not punctuation.

Put the real deadline in text

Because a rendered countdown cannot know the real time, it should always be accompanied by a plain statement of the date, time and zone, both in the video's final frames and in the post caption or page copy. "Doors open Thursday, October 15, 2:00 PM ET / 7:00 PM BST" is accurate for every viewer on every day; "2 days left" in a video is only accurate on the day it was posted.

If your team produces many variants of the same countdown, turning the composition into an editable template for editors saves hours. Our guide to motion graphics templates for editors explains how to expose the duration, date and zone text as safe, lockable controls.

Live clock-driven countdowns: strengths, limits and how to build one well

A live countdown is the right tool whenever the number on screen must match real time in front of an audience: the pre-show screen on a live stream, a presenter's timer, a break clock at an event, or a broadcast counting down to a result. Its value is that it calculates rather than plays back, so it absorbs late starts, cutaways and schedule changes without anyone noticing.

Pros

  • Counts against a real clock, so it is right whenever a viewer joins the stream.
  • The target time can be changed on the fly if the schedule slips.
  • The operator or logic controls the end state: switch to a live scene, a holding card or a revised time.
  • One graphics package serves many events once built, with only the target time and text changing.

Cons

  • More systems involved, so more ways to fail: a wrong system clock, a stale browser source, a crashed machine.
  • Visual complexity is limited by what renders reliably in real time on the production machine.
  • Needs rehearsal and an operator who understands the graphic, not just the switcher.
  • Viewers watching a replay later see a countdown that no longer means anything unless it is trimmed.

Count to an absolute target, never a duration

The single most important rule for a live countdown is to count to an absolute target time, such as 18:00:00 UTC on a specific date, rather than starting a ten-minute timer when someone presses a button. A duration-based timer inherits every human delay; an absolute target is right no matter when the graphic is loaded. Store the target in UTC, display it in the audience's zone, and have one person own it on show day.

Sync the machine clock

A live countdown is only as accurate as the clock of the computer rendering it. Make sure the production machine syncs to network time before the show, and check it against a known reference during rehearsal. A graphics machine that has been offline for weeks can be noticeably off, and the countdown will confidently display the wrong time.

Plan the handoff at zero

The most common live failure is not a wrong number; it is a countdown that reaches zero while the show is not ready. Decide in advance what happens: the graphic switches to "Starting shortly", or the operator holds on a branded card, or the target is moved and the audience is told. What should never happen is a clock showing negative numbers, or sitting on 00:00 for five minutes. For wider guidance on building live on-air graphics, see our article on broadcast graphics and lower thirds, and for data-driven live graphics under real deadline pressure, the approach in election results graphics transfers directly to countdowns.

Replay and on-demand versions

Streams live on as replays. A pre-show countdown that was right at the time is noise for someone watching next week. Trim the countdown from the on-demand version, or replace it with a short title card, and keep the replay's description accurate about when the event originally took place.

Embedded web and email countdowns: strengths, limits and how to build one well

Embedded countdowns live where people make decisions: landing pages, checkout pages, registration forms and emails. They are the only option that can localize automatically, because they run on the viewer's device and can read its time zone. They are also the option most often abused, because a few lines of code can make a countdown say anything.

Pros

  • Can show the deadline in each viewer's own time zone automatically.
  • Can pair the animated counter with a live text statement of the exact date and time.
  • Can swap content at zero, for example from "Register now" to "Registration closed" or a replay link.
  • Reusable once built; later campaigns only change the target time and copy.

Cons

  • Relies on the viewer's device clock, which is usually right but not always.
  • Email countdown images only show the remaining time at the moment of opening, and some clients cache them.
  • Design is constrained by page performance, web fonts and the need to stay readable at small sizes.
  • Easy to misuse as a fake scarcity timer, which damages trust and can raise legal questions.

Calculate from a fixed target on every tick

A web countdown should compute the remaining time on each update as the difference between a fixed target, written as a full timestamp with its UTC offset, and the current time. Scripts that simply subtract one second per tick drift when a browser throttles background tabs, so the timer falls behind while the tab is hidden. Recalculating from the target on every tick avoids that. If accuracy truly matters, for instance for a ticket release, compare against a server time on page load and correct for the difference with the device clock.

The evergreen timer problem

Some countdown plugins offer "evergreen" timers that start a fresh countdown for each visitor, often stored in a cookie. Clear the cookie or open another browser and the deadline resets. If the offer genuinely ends for each person after a period, say so plainly. If it does not, a per-visitor countdown is a fake deadline, and people notice. Screenshots of two different "ending soon" timers for the same offer travel fast, and the reputational damage outlasts the campaign.

Accessibility on the page

A counter that updates every second is movement that starts automatically and continues for a long time, so it should offer a way to pause or hide it, or be accompanied by a static text version of the deadline. Screen readers are the other trap: if the counter is marked as a live region, some assistive technologies will try to announce it every second, which makes the page unusable. Mark the ticking counter so it is not announced continuously, and provide a separate plain text sentence such as "Registration closes on October 15 at 2:00 PM Eastern Time" that assistive technology reads once.

Email specifics

Email countdowns are generated images, so they show the right remaining time when the email is opened and then stop. Some email clients and privacy features preload or cache images, which can mean the countdown reflects the time of caching rather than the time of opening. Always include the exact deadline, with its time zone, as live text in the email body, and treat the image as decoration, not the source of truth.

A common assumption is that a countdown that resets for each visitor is a harmless conversion tactic that everyone uses. In reality, a deadline that is not real is a misleading claim about the offer. It damages trust as soon as someone notices the reset, and advertising law in many markets treats false urgency as a deceptive practice. Use real deadlines, or no countdown at all.

Time zones, daylight saving and localization

Time zones cause more countdown complaints than any design decision. The rule from the reference material is simple: a countdown must state the zone or localize. In practice there are three workable approaches, and the right one depends on the placement.

State one zone clearly

For rendered video and most live graphics, pick one reference zone and write it out. Use the abbreviation your audience recognizes, and consider adding a second or third major zone if the audience is international. "2:00 PM ET" is clear to a US audience; "2:00 PM ET / 7:00 PM BST / 11:30 PM IST" serves a global one. UTC alone is precise but many general audiences do not convert from it comfortably.

Localize automatically

On the web, show the deadline in the viewer's local zone and name that zone: "Closes 7:00 PM your time (British Summer Time)". Localization removes the conversion burden, but the source must still be a single absolute timestamp so every viewer counts to the same instant.

Watch the daylight saving gap

Daylight saving transitions do not happen on the same date everywhere. The United States leaves daylight saving time on the first Sunday in November, while the United Kingdom and the European Union do so on the last Sunday in October. For roughly a week each autumn, and for a few weeks each spring, the gap between New York and London is four hours instead of five. A countdown graphic that hard-codes "7:00 PM BST" for a 2:00 PM ET event scheduled in that window will be wrong. Always calculate the secondary zones for the actual event date, not for today.

Localization goes beyond zones: date formats differ (10/05 means October 5 in the US and May 10 in much of the world), some audiences expect a 24-hour clock, and translated labels such as "days", "hours" and "minutes" vary widely in length. Our guide to localizing motion graphics covers the layout and text expansion side, which matters when one countdown design must work in several languages.

One firm rule: never write dates as all-numeric in a countdown aimed at an international audience. Spell the month, include the weekday and name the time zone. "Thursday, October 15, 2:00 PM ET" cannot be misread; "10/15 14:00" can.

A worked example: one webinar, three countdowns

The following example is illustrative, not a client project. It shows how the framework applies to a common situation: a software company running a live product webinar for customers in North America, the UK and India, promoted over two weeks.

The webinar starts on Thursday, October 15 at 2:00 PM Eastern Daylight Time. That is 18:00 UTC, 7:00 PM British Summer Time and 11:30 PM India Standard Time. Because the date falls before both the UK and US clock changes, these offsets are correct for that day; a webinar two weeks later would need different UK conversions.

PlacementBuild optionWhat it showsHow accuracy is protected
Social teaser, posted daily for five daysRendered video, 15 seconds, square and verticalA stylized 10-second countdown ending on the date, time and three zonesThe countdown is choreography only; the real deadline is stated in the end card and caption
Registration landing pageEmbedded web countdownDays, hours and minutes to start, plus the time in the viewer's own zoneCounts to a fixed UTC timestamp; text version below; switches to "Watch the replay" at zero
Reminder email, sent 24 hours beforeGenerated countdown imageHours and minutes remaining at openingExact time and zones in live text; image treated as decoration
Stream pre-show, from 1:50 PM ETLive HTML graphic in the streaming softwareA 10-minute countdown to start, with music bedCounts to 18:00:00 UTC from a network-synced machine; operator holds on "Starting shortly" if needed
On-demand replayEdited recordingNo countdown; a title card insteadPre-show trimmed so the replay starts with content

Notice that no single asset does every job. The social teaser is allowed to be purely cinematic because it never pretends to know the real time. The landing page carries the burden of accuracy and localization. The stream uses a live graphic because a late start of even ninety seconds would make a rendered 10-minute loop hit zero while the presenter is still adjusting their microphone.

Effort in this example

The effort involved varies with team and tooling, but the shape is consistent. The rendered teaser is mostly design and animation time, with cheap versioning afterward. The embedded countdown is a modest development task the first time and nearly free to reuse. The live graphic takes setup and a rehearsal, plus an operator's attention during the show. Budget time for the rehearsal specifically: it is where wrong clocks, stale browser sources and missing end states are caught.

Design details that make any countdown readable

Whichever build you choose, the same design principles decide whether people can read the timer at a glance.

  • Size for the smallest screen. Design the digits for the phone viewer, not the edit suite monitor. Numbers should be the largest element in the frame, with labels such as "hours" clearly secondary.
  • Use fixed-width figures. Tabular figures stop the counter from shifting as digits change, which is the most common reason countdowns look amateur.
  • Show only the units that matter. Seven days out, seconds are noise; show days and hours. In the final hour, show minutes and seconds. Units that change too fast to read add movement without information.
  • Keep contrast high. Digits on busy footage or gradients disappear. Our practical guide to color in motion design covers contrast choices that hold up on compressed video.
  • Animate the change, not the whole frame. A subtle flip, slide or fade on the digit that changes is enough. Constant camera movement, particles and pulsing all compete with the number the viewer came to read.
  • Treat sound as structure. Ticks, risers and a hit at zero make a countdown feel alive, but a tick every second for ten minutes is exhausting. Our article on sound design for motion graphics explains how to build tension without fatigue.

A countdown makes a promise the audience can check. Get the time, the zone and the ending right before you spend anything on how it looks.

Testing the end state and the failure modes

The end state is where countdowns fail most visibly, and it is the part teams test least, because in normal review nobody waits for the timer to finish. Test it deliberately. For a rendered file, scrub to the last second and watch the final frames: does it land on a clear message, or does it cut to black? For a live graphic, set the target a minute ahead during rehearsal and watch it reach zero. For a web countdown, set the target to a few minutes ahead in a staging environment, then leave the page open and see what happens at zero, after an hour, and after reloading the next day.

The failure modes to test for are consistent across projects:

  • Negative numbers. The counter keeps subtracting past zero and shows -00:01:12.
  • The frozen zero. The counter sits at 00:00:00 for days after the event, which tells every visitor the page is abandoned. Timers that expire but keep displaying are one of the mistakes to avoid.
  • The reset. A reload, a new browser or a cleared cookie restarts the deadline.
  • The wrong hour. The countdown is right in the designer's zone and an hour off for anyone on the other side of a daylight saving boundary.
  • The cached image. An email countdown shows a stale value because a client prefetched it.
  • The silent overrun. A live countdown reaches zero while the show is not ready, and nobody has decided what the screen should show.

Write the end state into the brief. For each countdown placement, record what it shows at zero, what it shows an hour later and what it shows a week later. If nobody can answer, the countdown is not ready to publish.

Accessibility testing belongs in the same pass. Check that a moving counter can be paused or that a static text version of the deadline is present and near it, that a screen reader encounters the deadline once as a sentence rather than as a stream of changing numbers, and that the countdown does not flash. Motion that is fine for most viewers can be difficult for people with vestibular disorders or attention-related conditions, which is why the pause control or the text alternative is not optional.

Recommendations by scenario

Here is how the criteria play out in the situations we see most often. In each case, the verdict weights the criteria differently, which is why the answers differ.

Social teasers and launch announcements

The job here is anticipation. Viewers see the post hours or days after it was published, so no animated number can be accurate for all of them. Polish, reliability and cost dominate the decision, and accuracy is handled by stating the date, time and zone in text.

Verdict Use a rendered video countdown, keep the counted duration short and stylized, and end every version on a card with the real date, time and time zone. Never show "3 days left" in a file that might be watched on any day.

Live streams, webinars and live events

The job is coordination against real time. People join at different moments, streams start late and schedules slip. Accuracy and end-state control dominate, and polish is secondary. If you are combining live graphics with camera footage, our guide to blending graphics with live footage covers the compositing side.

Verdict Use a live, clock-driven countdown that counts to an absolute UTC target on a network-synced machine, rehearse the zero moment, and decide the holding state in advance. Reserve rendered loops for walk-in music beds with no visible numbers, or start them only when you are certain of the time.

Registration pages, product drops and real offers

The job is communicating a real deadline to people in many time zones who make decisions on the page. Accuracy, localization and honesty dominate. If the deadline is not real, the right countdown is no countdown.

Verdict Use an embedded countdown that counts to one fixed timestamp for every visitor, localizes the displayed time, sits next to a plain text statement of the deadline and swaps to a clear closed or replay state at zero. Do not use per-visitor or evergreen timers for offers that do not genuinely end.

Presentations, exhibits and in-venue screens

Countdowns on stage screens and in venues sit between the categories. A timer that opens a keynote is choreography and can be rendered; a break clock on a lobby screen must be live. The same logic applies to installations, as in museum and exhibit installations, where screens run unattended for weeks and the end state must look after itself.

When to bring in a motion graphics team

A simple countdown for an internal meeting or a casual social post does not need specialist help. The reference guidance is clear on the threshold: bring in help when countdowns support a real launch. That is when the costs of an error are public, the audience is spread across time zones, and several placements must stay consistent with one another.

A specialist team earns its keep in four places. First, scoping: deciding which placement needs which build, and writing the end states and time zones into the brief. Our guide to motion graphics briefs and scoping shows how to capture those requirements before anyone opens an animation tool. Second, building templates so that date, time and zone changes do not require a designer each time. Third, setting up and rehearsing live graphics with a clear owner for the target time. Fourth, testing: the end state, the daylight saving gap, the replay and the accessibility checks that are easy to skip on a deadline.

If you are planning a launch, event or live stream and want countdown and timer graphics that are accurate, readable and honest, our motion graphics services cover rendered, live and embedded builds, and we can advise on which combination fits your placements.

Before any countdown goes live, confirm the following:

  • Every placement has a chosen build: rendered, live or embedded.
  • The target is stored as one absolute timestamp in UTC.
  • The time zone is stated in text or localized for every viewer.
  • Secondary zones are calculated for the event date, not today.
  • A plain text version of the deadline sits next to every moving counter.
  • Moving counters can be paused, or a text alternative is provided.
  • Digits use tabular figures and stay legible on a phone.
  • The zero state, the hour-after state and the week-after state are designed and tested.
  • No timer resets per visitor, and no deadline is invented.
  • Live graphics run on a network-synced machine and have been rehearsed to zero.

Where this comes from

The figures and practices above come from the sources listed.

Working on something like this?

We take on Motion Graphics & Animation work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.

Where to go next

Spotted something wrong? Report an error on this page. We correct on the page and say what changed.

Frequently asked questions

It depends on whether the number has to match real time. A rendered video is best for social teasers and openers where the countdown is choreography, while a live, clock-driven graphic is best for streams and events where people join at different moments. Many launches use both, each in the placement it suits.
A rendered file counts from when playback starts, so any delay in starting it shifts the zero moment. Long countdowns built on frame counts at 29.97 frames per second can also drift by a few seconds per hour. For anything that must hit zero at an exact time, use a live graphic that counts to a fixed target.
Either state one reference zone plus the main audience zones in plain text, or localize the displayed time on the web so each viewer sees their own zone named. Always calculate the conversions for the actual event date, because the US, UK and EU change clocks on different dates.
Whether a specific timer breaks the law depends on the market and the facts, so take legal advice for your situation. The general principle in advertising law is that claims must be truthful, and a deadline that is not real can be a misleading claim. It also damages trust quickly once customers notice the reset.
Give users a way to pause or hide a counter that keeps moving, or provide a static text version of the deadline nearby. Avoid having screen readers announce the number every second, and present the deadline once as a readable sentence with the date, time and time zone.
It should switch to a clear message such as a live scene, a starting shortly card, a registration closed notice or a replay link. It should never show negative numbers or stay frozen at zero for days. Decide the zero state, the state an hour later and the state a week later before publishing.
They can, using an image generated when the email is opened, but the image shows only the remaining time at that moment and does not keep counting. Some email clients cache images, so the value can be stale. Always put the exact deadline and time zone in the email text as well.
All services

The work behind this article, and what it costs.

Tomas Lindqvist

Picture and sound. Writes about editing, color, loudness and delivery specifications, including the ones that get deliveries rejected.

Keep reading

More in Motion Graphics & Animation