When your site goes down

My website is down — how to fix it

July 18, 20266 min read

A red emergency light glowing in the dark — the moment a site goes down.

Your website is down and your pulse is up. The fastest way through this isn't to start randomly restarting things — it's to work down a short list in order, cheapest check first, so you find the actual cause instead of guessing. Here's that list.

Step 0: confirm it's really down

Before anything else, make sure the site is down for everyone, not just you. A local cache, a bad wifi, or a stale DNS entry can fake an outage. Thirty seconds of checking saves you an hour of fixing a problem that isn't there — is it down or just me? walks the quick version.

The ordered checklist

Once it's genuinely down, go in this order. Each step rules out a whole category, so you narrow fast:

Read the actual error. The browser is telling you a lot. A certificate warning, a 500, a 404, a connection timeout, and a "this site can't be reached" are four different problems. Note exactly what you see — it points at the layer that broke.
Certificate or domain expired? A full-page security warning usually means an expired SSL certificate. A "server not found" can mean a lapsed domain registration. Both are calendar events with abrupt, total effects — rule them out early because they're common and quick to confirm.
Did you just deploy? If it broke right after a push, that's your suspect. Check the build and deploy logs for a failed build or a runtime error, and roll back to the last working version if you can. A rollback buys you time to diagnose calmly.
Is the host or a dependency down? Check your hosting provider's status page and those of the services you depend on — database, auth, payments, APIs. Your app can be blameless and still down because something under it isn't.
Is it asleep, not down? On a free tier, "down" is sometimes just a service that spun down when idle and is slow to wake. A very slow first load that then works points here.
Check the server and logs. If none of the above, look at the application itself — is the process running, is the database reachable, what do the error logs say in the minutes before it went dark?

Write down what you see at each step. When it's back up, that trail is how you find the root cause and stop it recurring — panic-fixing without notes means you learn nothing and it happens again.

Get it back, then find the why

Priority one is restoring service — roll back, renew, restart, whatever gets users back in. Priority two, once the pressure's off, is the root cause, so this is the last time that particular thing takes you down. The two are different jobs; don't let the second stop you doing the first.

The real fix: find out before your users do

The worst part of most outages isn't the fix — it's that you found out late, from a customer, after it had been down for an hour. Every minute between "it broke" and "I noticed" is pure avoidable damage.

A monitor watching from outside your stack closes that gap: the moment the site stops answering, you get an email or a text, and you're working the checklist above while it's a five-minute blip instead of an afternoon. If you're weighing options, we compare the best uptime monitoring for indie hackers.

Be the first to know, not the last.

Join Tell Me When Down free and we'll watch your site around the clock from outside your stack. The moment it goes down — cert, deploy, host, or crash — you get an alert in minutes, so you're fixing it before your users even notice.

Watch my sitefree · no card required

Step 0: confirm it's really down

The ordered checklist

Once it's genuinely down, go in this order. Each step rules out a whole category, so you narrow fast:

Read the actual error. The browser is telling you a lot. A certificate warning, a 500, a 404, a connection timeout, and a "this site can't be reached" are four different problems. Note exactly what you see — it points at the layer that broke.
Certificate or domain expired? A full-page security warning usually means an expired SSL certificate. A "server not found" can mean a lapsed domain registration. Both are calendar events with abrupt, total effects — rule them out early because they're common and quick to confirm.
Did you just deploy? If it broke right after a push, that's your suspect. Check the build and deploy logs for a failed build or a runtime error, and roll back to the last working version if you can. A rollback buys you time to diagnose calmly.
Is the host or a dependency down? Check your hosting provider's status page and those of the services you depend on — database, auth, payments, APIs. Your app can be blameless and still down because something under it isn't.
Is it asleep, not down? On a free tier, "down" is sometimes just a service that spun down when idle and is slow to wake. A very slow first load that then works points here.
Check the server and logs. If none of the above, look at the application itself — is the process running, is the database reachable, what do the error logs say in the minutes before it went dark?

Write down what you see at each step. When it's back up, that trail is how you find the root cause and stop it recurring — panic-fixing without notes means you learn nothing and it happens again.