Check your domains and certificates in bulk
Almost every “our website is down” story that turns out to be an expiry starts the same way: nothing broke, nobody was attacked — a date simply passed while nobody was watching that particular name. This guide explains why domains and certificates lapse, why they run on two different clocks, and the short bulk routine — built around the bulk domain checker — that turns a portfolio of scattered dates into one calm monthly habit.
Last updated:
Why domains and certificates lapse
Renewal notices go where the account points, and accounts point at people. The classic failure is a renewal email sent to a departed employee’s mailbox — the registrar did its job, the inbox did not, and the first “notice” anyone sees is the site going dark. A close second is pure organisational fog: the registrar is not the host is not the DNS provider, and each team assumes another one owns renewal. Add an auto-renew card that itself expired, a domain registered years ago by an agency that no longer answers, and a portfolio that grew by acquisition, and lapse stops looking like carelessness. It is the default outcome of a date nobody owns.
Certificates lapse differently, which is why they surprise different people. For years a certificate could be installed once and forgotten for years; then issuance moved to automation — short lifetimes, automated renewal, a CA or browser policy change — and the automation itself became the thing that breaks silently: a validation method retired, a DNS challenge aimed at a zone that moved, a cron job on a retired server. Nothing about the site changed, yet one morning browsers refuse it. The lesson in both stories is the same: expiry is not an event you hear about. It is a date you either look at on purpose, or meet by accident in front of your users.
Two clocks, not one
Every name you care about carries two independent deadlines. The domain clock is the registration: held at a registrar, usually one to ten years, and when it runs out the name stops resolving, mail stops routing, and eventually a stranger can register it and inherit its traffic and its password-reset emails. The certificate clock is the TLS certificate on the server or CDN: issued by a different organisation entirely, usually for a year or less, and when it runs out browsers block the site even though the domain has years left. Renewing one never touches the other. A checklist that tracks only domains will be ambushed by certificates, and a certificate dashboard that ignores registrations will be ambushed by the registrar.
That is why a useful bulk view always shows both dates per row and sorts by whichever comes first. A domain with nine years left and a certificate with nine days left is a nine-day problem. A certificate freshly renewed for a year on a domain that expires next month is a one-month problem. The soonest clock is the real deadline, and training yourself to read portfolios that way — soonest first, everything else context — is most of the skill. The bulk domain checker is built exactly on that reading: one row per name, both clocks visible, the whole table ordered by the deadline that will actually bite.
A monthly bulk-check routine
The routine is deliberately small, because a routine that hurts does not survive. Keep one canonical list of names — every production domain, every redirect that still matters, every client name you would get a phone call about — in one file, one domain per line. Once a month, or once a quarter for a small and stable list, paste that file into the bulk domain checker and read the table top-down. Anything beyond 90 days needs nothing. Anything inside 90 days gets a calendar entry. Anything inside 30 days gets handled in that sitting, not noted for later. Export the CSV and attach it to the ticket or the monthly ops note, so next month’s run can be diffed against this one.
Two habits make the routine trustworthy. First, grow the list deliberately: every launch, migration and acquisition ends with “add the name to the list”, and every decommission ends with removing it — a list that drifts from reality gives false calm. Second, check the owner, not just the date: for every name inside 90 days, confirm which registrar account holds it and who can log into that account today. A renewal you cannot perform because the account belongs to a former agency is not a renewal problem you have 90 days to solve; it is an access problem you have 90 days to solve, and those take longer. The bulk table gives you the dates in minutes; spend the saved time on ownership.
When something is within 30 days
Inside 30 days, order matters. Renew the domain first. A lapsed registration takes the name itself away — resolution, mail, and eventually ownership — while a lapsed certificate, however ugly the browser warning, leaves the name yours and is fixable in an afternoon. Domain first, certificate second, every time. Renew for multiple years when the registrar allows it: it is the cheapest way to move a name out of the danger window for a long time, and it protects against next year’s forgotten notice as well as this one. Then confirm the renewal actually landed — check the new expiry date in the bulk table on the next run rather than trusting a payment receipt.
Then handle the certificate, and while you are there, check the registrar account owner as a separate task. Who receives renewal notices for this account? Is the payment method current, and does auto-renew fail loudly or silently at this registrar? If the account is held by an agency, a former employee or a personal email address, moving it to a role account the organisation controls is worth more than any single renewal — it removes the entire class of failure, not just this instance. Note what you changed next to the CSV you exported, so the next person inherits a system, not a mystery.
When a single check is enough
Bulk is for portfolios; it is not the only lens. When you are deep in one name’s problem — a migration, a registrar transfer, a “why does mail fail” investigation — the single tools show more: the domain expiry checker gives one domain’s full registry record, status codes and DNS, and the SSL checker gives one certificate’s chain, names and protocol detail. If you own exactly one domain and remember it the way you remember your own birthday, a single check when you think of it is honestly enough; bulk earns its keep the moment the honest answer to “how many domains do we have?” involves counting, asking around, or opening more than one registrar account.
The dividing line is memory. Anything a team must remember together, it will eventually forget together — that is what the list, the routine and the table are for. Start the list today, while it is short enough to write from memory, run it through the bulk domain checker, and let the soonest clock on the page tell you whether you have a quiet quarter or a busy week. Either answer is better than the one an expired domain gives you.
Frequently asked questions
How often should I check my domains in bulk?
Monthly is the comfortable rhythm for most portfolios; quarterly is enough for a small, stable list whose soonest expiry is far away. The real rule is interval versus warning window: if you check every 90 days, a domain can enter its last 30 days between runs, so monthly checks against a 30-day action threshold leave margin in both directions. Any name already inside 90 days deserves its own calendar reminder, not just a place in the routine.
Something expires in under 30 days. What do I do first?
Renew the domain registration first — losing the name itself is the irreversible failure — then deal with the certificate. Confirm which registrar account holds the domain and that someone on your team can log into it today; if access is the blocker, start there immediately, because account recovery is slower than payment. After renewing, re-run the bulk check and confirm the new date actually shows, rather than trusting a receipt.
Does renewing a domain renew its certificate too?
No. The domain registration (registrar, typically one to ten years) and the TLS certificate (a certificate authority, typically about a year or less, living on your server or CDN) are separate contracts with separate organisations. Renewing, transferring or auto-renewing one has no effect on the other — which is why a bulk view shows both dates for every name and sorts by whichever expires first.