Zone Control
TTL — Turning Propagation Into a Window You Can Promise
Clients do not want to be told a change takes 'up to 48 hours'. They want a start time, an end time and a person who will be awake for both.
Straight answer first
TTL is how long resolvers may keep a DNS answer before asking again, and for a reseller it is the dial that converts an open-ended wait into a maintenance window you can put in an email a week in advance.
The catch is that the TTL governing a change is the one that was already in place before you made it. Below: why you are selling a window rather than a wait, the lead time nobody quotes for, batching a migration across an estate, and putting the values back.
Written by the Hosting Seller staff · Checked 24 August 2026
100+
Terms, defined for resellers
2 min
To read between tickets
Plain
English, not marketing copy
24/7
Counter cover, yours included
Long values measured in hours cut lookup traffic and add resilience. Short values measured in minutes let a change spread fast. Neither is right permanently, which is why the setting is a planning tool rather than a preference.
That is where the ritual comes from: drop the TTLs a day ahead, make the change, put them back up afterwards. Do that and the cutover runs to your timetable instead of to whatever value somebody set three years ago and forgot.
You are selling a window, not a wait
'Up to 48 hours' is the answer of somebody who did not plan. A five-minute TTL set the day before turns the same job into 'the switch happens at nine, everything follows within about ten minutes, and I am on the phone until half past'.
That difference is worth real money in a proposal. It is also the difference between a client scheduling their marketing around your work and hoping it goes well.
The lead time nobody puts in the quote
Lowering a TTL obeys the old value first. A resolver holding the record with four hours left will not see the new five-minute setting until it refreshes, so the reduction has to happen at least one full old-TTL period before the change.
In practice that means a step the day before the migration, on every record you intend to touch. Build it into the plan and the client's window is accurate; skip it and the window is fiction.
Batching a migration across an estate
Moving twenty client sites is twenty TTL reductions the day before and twenty restorations afterwards, which is precisely the sort of work that gets half done. Keep a list with a tick per account and per stage.
Stagger the cutovers rather than doing them all at nine o'clock. If something is wrong with the first three, you would rather find out with seventeen untouched than with all twenty in flight.
Putting the values back
A five-minute TTL left in place forever taxes resolvers for flexibility you are not using, and it removes a small piece of resilience during a supplier outage. Restore an hour or more on stable records the next morning.
This is the step that gets skipped because the migration already worked. Put it on the checklist as a separate line with its own tick, or it will not happen on the accounts that went smoothly.
Definitions with the commercial consequence attached
Resellers get handed the vocabulary of four different trades at once: registry, panel, mail and server. This glossary translates all of it into what the thing costs you and what the client sees.
Private nameservers and a panel wearing your logo mean the only company a client reads about is yours. Ours stays out of sight.
- One hundred terms, no marketing detours
- Costed per account wherever cost applies
- The scale problem called out at each term
- Neighbouring concepts linked, never siloed
Why Hosting Seller
On every plan, as standard
A window you can put in writing
Replace 'up to 48 hours' with a start time, an expected settle time and a person who is available for both.
The lead-time rule, stated plainly
Why a TTL reduction obeys the old value first, and how far ahead of the cutover it therefore has to happen.
Twenty accounts, staggered
How to batch a portfolio migration so a mistake on the first three does not arrive on all twenty at once.
Sized for a portfolio
Everything here is written for the person holding forty accounts, not the person holding one.
Paragraphs you can forward
Several sections are worded so they can go straight to a client without being translated first.
Grounded in kit you resell
Examples point at cPanel, WHM and hosting you would actually put a client on, not at an abstract diagram.
First Steps
From choosing to live
- 1
Drop the TTLs a day before, not an hour
The reduction is only visible once the old value has expired, so schedule it at least one full old-TTL period ahead of the change you actually care about.
- 2
Stagger the cutovers across the batch
Three accounts, check, then the rest. The point of a window is that you can stop inside it, and you cannot stop if everything moved at once.
- 3
Restore the values the next morning
A separate line on the checklist with its own tick. Short TTLs left permanently in place cost you resilience in exchange for flexibility nobody is using.
In the Box
Packed with every plan
- TTLs lowered a full old-TTL period before every client cutover
- Values restored the following morning, tracked per account
- Site migration handled by our staff at no charge, on every account you bring
- Staging copies, so client sign-off happens before anything goes live
- Daily backups on every plan, with restores you run yourself
- Upgrades applied to the account in place, with no move between plans
- NVMe SSD storage on every shelf, not just the top one
- LiteSpeed caching at the server, so you are not billing for a cache plugin
- Real people on the counter at any hour, including yours
- Thirty days money-back on hosting plans, seven on reseller
Across the Counter
Things people ask us all the time
What window do I actually promise a client?
Whatever the TTL you set the day before allows, plus a margin. With records at five minutes, tell the client the switch happens at a stated time and that everything should settle within about fifteen. Promise a window you have engineered rather than repeating the '48 hours' line the industry inherited.
I lowered the TTL and the change is still slow. What did I miss?
The reduction itself was subject to the old value. A resolver holding the record with hours left on the clock does not learn about the new five-minute setting until it refreshes. Lower it one full old-TTL period before the real change, and the second change is quick.
Can I move twenty client sites in one night?
Yes, if the day before was spent lowering TTLs and the night itself is staggered rather than simultaneous. Do three, verify externally, then continue. The constraint is your ability to check, not the platform's ability to serve.
The client's DNS is at their registrar and they will not give me access. Now what?
Send them the exact TTL change to make, in writing, at least a day before the cutover, and confirm from an external lookup that it took effect. If they will not do it, the window widens to the old TTL and you say so in advance. Never promise a timescale you do not control.
Read next
SSL Certificates
SSL free on every account, with wildcard and EV on the shelf for the client whose compliance team asks.
Secure Hosting
Imunify360, account isolation and hardened defaults for clients in sectors that audit their suppliers.
Moving your site to another host? Start with this checklist.
A step-by-step order of work for a move your visitors never spot: which files to copy first, how to carry email across without losing one message, the right moment to repoint DNS, and the two mistakes behind nearly every hour of downtime people ring us about.
One WHM panel, every client account.
Free SSL on every account, daily backups you restore yourself, and support that answers at three in the morning so you do not have to.
See SSL Certificates plans