What to do when your website goes down at 2 a.m.
A sequence for the owner who gets the alert in the middle of the night. What to check in what order, what not to touch, and who to wake.
The short answer
Your phone buzzes at 2 a.m.: a monitoring alert, or a customer on the other side of the world saying the site is down. Before touching anything, establish two facts: is it down for everyone, and at which layer? A third-party checker answers the first in thirty seconds. The second is a short walk down four layers: domain and DNS, certificate, hosting platform, the site itself. Each has a different fix and a different party. The worst thing you can do is start changing settings at random, which is how most 2 a.m. damage is done.
If you have a partner with monitoring, they are probably already awake and working. If you do not, this is what they would do.
The sequence
- Confirm it is down for others. Use an online “is it down for everyone” checker or ask someone on a different network. If it works for them, the problem is your device or network, not the site.
- Look at the error. A browser error about the certificate, a “site cannot be reached”, a platform error page, or your own site showing an error each point at a different layer.
- Check the domain. Has it expired? Look it up with a public domain lookup. An expired domain shows a parking page or nothing at all.
- Check DNS. Does the domain still point where it should? A DNS lookup tool shows the current records. Was anything changed today?
- Check the certificate. Browser says “not secure” or “certificate expired”: the site is up but the certificate lapsed. Renewal is the fix; do not disable HTTPS.
- Check the platform’s status page and your hosting dashboard. A provider incident means waiting, not fixing.
- Check the last deploy. If something was published in the last hours, roll back to the previous version. On a modern platform that is one action and safe.
- Only then consider the site itself: logs, errors, a third-party script that is down and blocking the page.
What not to do
| Temptation | Why not |
|---|---|
| Change DNS records to “try something” | DNS changes take time to propagate and create a second outage on top of the first |
| Disable HTTPS to get past a certificate error | Exposes visitors and breaks browsers’ memory of the site; renew instead |
| Reinstall, update or “repair” from the hosting panel | Destroys the evidence and often the site; rollback is the safe action |
| Restore a backup over the live site without knowing the cause | If the cause is the platform or DNS, the restore does nothing and may lose recent data |
| Post publicly that you were hacked | You do not know that yet; expiries and bad deploys look the same from outside |
Who to wake
Your partner, if you have one and the agreement covers critical incidents at night. That is what the arrangement is for, and they have the access, the monitoring and the sequence above already running. If you have no partner, you are the on-call person, and the sequence above is yours. In either case, once the site is back, insist on a written incident summary: what failed, how long, why, and what changes so it does not recur.
What this means for you
A site down at night is stressful and usually simple. Confirm it is really down, find the layer, take the one action that layer needs, and do not improvise on top of it. Better still, have monitoring and a partner who is awake before you are, and a one-page runbook on your phone for the night they are not. Then ask why it happened, every time, so the same night does not repeat.
Frequently asked questions
Should we wake our developer for every outage?
For a confirmed outage of the whole site or checkout, yes, if that is the arrangement. That is what an on-call agreement is for. For a single page erroring or a slow site, a message they read in the morning is fine. The severity table in your agreement should say which is which; if there is no table, that is a conversation for next week.
Our host's status page says everything is fine, but the site is down. Who is wrong?
Probably both are right. The host's infrastructure is fine and your site has a problem of its own: an expired certificate, a bad deploy, a DNS change, a domain issue. Status pages describe the provider's layer, not yours. Work through the layers in order.
The site came back by itself. Do we still need to do anything?
Yes: find out why. A site that recovers on its own had a cause, and causes repeat. Ask for the incident summary: what failed, for how long, why, and what prevents it next time. An outage without a post-mortem is an outage scheduled to happen again.