DNS
TTL migration planner
When to drop a TTL before a DNS cutover, and the first moment the old value is actually gone.
Free, no accountIn your browser
What the record is set to right now - how long a resolver holds onto it before asking again.
How soon the new value - the new address, the new provider - has to actually be live.
Result
Drop the TTL in 1 hour and it is safe to flip in 2 hours
A 1 hour TTL dropped in 1 hour finishes its worst case right as the cutover target arrives.
- Info
Drop the TTL in 1 hour
Dropping it any earlier only means a longer wait doing nothing; any later and the old TTL's worst case has not finished expiring by the cutover target. in 1 hour is the latest moment that still clears in time.
- Info
This is the worst case, not the average one
A TTL is the longest a resolver is allowed to cache the old value, not a promise that every resolver will - most refresh sooner. But a browser's own cache, a corporate resolver with a floor under its TTLs, or a secondary that polled right before the drop can all hold on for the full 1 hour regardless, which is why the schedule here plans for the longest case rather than the typical one.
Migration milestones
| Milestone | When |
|---|---|
| Right now | now |
| Drop the TTL | in 1 hour |
| Your cutover target | in 2 hours |
| Old TTL fully expired - safe to flip | in 2 hours |
The last row lands on or before the cutover target, so flipping on schedule is safe.
What this is built from
- Current TTL
- 3600 seconds (1 hour)
- Old TTL may still linger (worst case)
- 1 hour
- Hours until cutover
- 2 hours
- This only knows the TTL you typed. A resolver, CDN or browser that ignores TTLs and caches on its own schedule is not accounted for, and some of the worst offenders do exactly that.
- The plan assumes the TTL on the record does not change again before the cutover. Dropping it twice, or raising it back up by habit before the change ships, resets the clock this plan is built on.
What this is
This ttl migration planner answers the one question every DNS cutover runs into: drop the TTL too late and some share of visitors are still being handed the old value when the change ships, drop it with room to spare and the wait before you can safely flip is longer than it needed to be. Give it the TTL sitting on the record now and how many hours away the actual change is, and it works out the latest moment that still clears in time, and the first moment the old value is guaranteed to have expired everywhere.
A TTL is not a promise that a resolver refreshes exactly on schedule - it is the longest a resolver is allowed to hold the old value before it has to ask again. Planning a cutover around the typical case instead of that worst case is how a migration ships clean for most visitors and quietly wrong for whoever happened to cache right before the change.
The arithmetic is one subtraction: the latest safe moment to drop the TTL is the cutover target minus the TTL itself, because that is exactly how long the old value can still be served out of someone else's cache after the drop. Drop it any later and that worst case has not finished by the time the change ships; drop it any earlier and nothing changes except how long you wait doing nothing.
How to read the result
The milestones table is the whole plan in four rows: now, when to drop the TTL, the cutover target as given, and the first instant the old TTL is guaranteed to have expired. When that last row falls on or before the cutover target the schedule is safe; when it falls after, the cutover is set earlier than this TTL allows for.
A TTL longer than the time left before cutover has no safe drop time at all - dropping it this instant is already the best available option, and the plan says by how much the target is missed rather than pretending a schedule exists that does not.
Common mistakes
What goes wrong most often, and how to tell.
- Dropping the TTL and flipping the record in the same breathLowering a TTL only changes how long a *future* cache lasts - it does nothing about a copy of the old value a resolver already cached under the old, longer TTL a minute before you touched it. That copy keeps being served for up to the old TTL regardless of what the record says now, which is the entire reason this plan counts from the drop rather than from the flip.
- Measuring the wait in "a while" instead of the TTL itselfA 24-hour TTL and a 300-second one need completely different lead times, and "give it some time" treats them the same. The safe wait is exactly the old TTL, not a round number that felt long enough - a migration planned around "a few hours" for a record cached for a day still has stragglers on the old value a day later.
- Forgetting the TTL that was there before you lowered itOnce the TTL is already down to something small, it is tempting to plan the rest of the cutover around that new, short number. The cache that matters is whatever was cached under the *old* TTL right before the drop, which can still be running out its full old lifetime long after the record itself says something shorter.
Questions
What people ask about this tool.
- Worst case, exactly as long as the old TTL was set to, counted from the moment you dropped it - not from whenever you happen to check. A resolver that cached the record one second before the drop can hold onto that old value for the old TTL's full length, whatever the record says now.
- Because the cost of being wrong is asymmetric: a visitor who gets the new value a little early loses nothing, but a visitor still handed the old value after a cutover can hit a dead address or the wrong mail server. Planning for the slowest resolver rather than the typical one is the only way to promise nobody is left on the old value past the target.
- Then there is no schedule that clears in time, and dropping the TTL immediately is already the best available move - this planner says so plainly rather than inventing a safe drop time that does not exist, and shows exactly how far past the original target the safe moment actually lands.
- Only for the next change. Once the new value is live and has been cached under whatever TTL the record now carries, this plan's job is finished - the window it describes is specifically the gap between dropping the old TTL and that old value finishing its last worst-case cache.
Use it from the API
The same check, as one request.