Your website is down: what to do in the first fifteen minutes

A site that stopped answering is rarely fixed in the code. The reflex is to open the editor: resist it for ten minutes. The fault is almost never where you would have looked first, and the ten minutes you spend narrowing it down save an hour of guessing. The order that works has five steps: confirm the outage is real, locate the layer at fault, find out what changed, say a word to the people who are about to notice, and only then repair.

The fifteen minutes, at a glance

There is nothing military about this schedule. It does one thing: it stops you spending the whole fifteen minutes on the first hypothesis that came to mind, which is also the one you most want to be true.

1. Confirm the outage, from outside

Your browser lies. It caches, it holds old DNS records, and your office network may be the only one in the world affected.

Three checks are enough, and they take under a minute:

• The site on mobile data, Wi-Fi off. If the page loads, the problem is your connection, not the site. It is the highest-yield test on the list.
• A private browsing window. It rules out an expired session, a browser extension, a service worker left behind by a deployment.
• Someone in another city. A regional carrier outage looks exactly like a server outage when seen from your desk.

If all three fail, the outage is real, and you know it before opening a single file. If one of them succeeds, you have just saved an hour hunting an outage that never existed.

2. Find out which layer failed

The exact error message beats any intuition. Write it down word for word, with the time, before going further: in half an hour you will not remember it, and it is the one piece of information nobody can reconstruct afterwards.

The three codes in the 500 family look alike and are not repaired the same way at all: what each code means is worth two minutes of reading before your first command.

3. Five commands that answer in thirty seconds

A terminal beats a browser for this step: it caches nothing and it hands you the raw status code.

curl -I https://example.com           # the status code, without the browser
dig +short example.com                # does the domain still point where it should
ping -c 3 example.com                 # is the machine reachable at all
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
tail -n 100 /var/log/nginx/error.log  # or storage/logs/laravel.log, depending on the stack

The first line alone separates "nothing answers" from "something answers badly", which are two unrelated outages. The second catches the case nobody suspects early enough: a DNS record edited last week and propagating only now. The last one is the one people always skip, and it is almost always the one holding the answer.

4. Ask what changed

Almost every outage follows a change, and the change is not always yours.

• A deployment this morning, however small, however "risk free".
• An automatic update overnight: system, plugin or dependency.
• A certificate that expired at 2am.
• A domain name that reached its renewal date.
• A failed payment at the host, with the notice sitting in spam.
• A third-party API that changed version without telling anyone.

In the rare case where nothing moved on your side, the change happened somewhere else, and no message will bring it to you: your host does not warn you, and it is not ill will, it is how their alerting is designed.

5. Say something, before you are asked

If the outage runs past ten minutes, three lines on the channel your customers actually read are worth more than a perfect explanation published three days later.

The site has been unavailable since 2:20pm. We have identified the cause and we are working on it. Next update at 3pm, in the same place.

That message says three things and not one more: since when, where you stand, when you will speak again. Do not promise a recovery time while the cause is unknown: a missed promise costs more than silence. For a client on a contract the incident will end up in the monthly report anyway, and it is better that it arrives there in your words rather than theirs.

6. The five moves that make it worse

• Restarting the server before reading the log. The restart usually wipes the trace of what broke. The outage returns two hours later and you know no more than before.
• Touching DNS. A zone change takes hours to propagate, and you have now added an outage on top of the outage.
• Deploying an untested fix. Under pressure, the odds of making things worse comfortably exceed the odds of repairing them.
• Flushing every cache at once. You lose the information that would have told you which one was at fault, and you hammer the database at the worst moment.
• Announcing a recovery time. While the cause is unknown, any deadline you announce is a deadline you will miss.

7. Afterwards, the only question that matters

Not why did it break: you know that now. The real question is: how long did it take me to find out?

If the answer is "a customer told me", the outage was not the incident. Being the last to know was. And the bill is not symbolic: what an hour of downtime really costs can be worked out, including for a site that sells nothing online.

That part is fixable in a few minutes: a check that runs by itself, an email the moment the site stops answering, another when it recovers. Two settings then matter as much as the tool itself, how often to check and what turns a check into an alert, without which you will merely have replaced silence with noise. And if you are still weighing a home-made script against an outside service, the honest comparison is in self-hosted or external monitoring.

When it is not an outage

One case deserves its own reflex, because it looks like an outage without being one: an expired certificate. The server answers perfectly; the browser refuses to show the page. Nothing in your application logs will mention it, restarting anything changes nothing, and the only clue is that red warning your visitors see before you do. It is also the one failure on this page that a visitor will never report to you, because a browser telling them the connection is not private does not read as your problem, it reads as a reason to leave.