Your Website Is Down: What to Do Now, Step by Step

If your website is down, the first thing to do is check whether it's down for everyone or only for you. Then read the error message, because it usually tells you who to contact: your domain registrar, your hosting provider or your developer. Most outages come from a short list of causes, and you can handle the first 15 minutes without touching any code.

This works for a marketing site, an online store or a web app with user logins. I'm a freelance developer based in Denmark, and maintaining existing systems is part of my work, so read what I say about maintenance agreements with that in mind. The rest applies whoever you end up calling.

The short answer: the error tells you who to call

What your browser shows you is the quickest clue. Match it against this table to find out who to contact first.

A simple rule: if it's about the domain or the server, start with the provider. If it's about something the site does (errors, logins, payments), start with your developer.

This guide covers the first few hours. How to stop outages from happening in the first place is the subject of my complete guide to web application maintenance.

Steps 1-4: the first 15 minutes

What you do in the first few minutes often decides whether an outage lasts an hour or a day. You're not there to fix it. You're there to give the person who will fix it a head start.

1. Confirm it's down for everyone. Open the site on your phone with Wi-Fi switched off, then try a different browser on your computer. A free checker such as downforeveryoneorjustme.com gives you a second opinion. If the site loads elsewhere, the problem is on your end and you can skip the panic call.
2. Write down what you see. Take a screenshot, note the time and list which pages fail: the homepage, checkout, login or everything. Also note anything that changed recently, such as a plugin update, a new campaign driving traffic, a hosting move or an expired company card.
3. Check the boring stuff. Log in to your domain registrar and your hosting account and look for unpaid invoices, expired subscriptions and incident emails. Large providers such as Cloudflare, AWS and DigitalOcean publish live status pages, and many smaller hosts do too. An expired domain or a declined card is a dull cause, but a common one, and often a five-minute fix.
4. Contact the right person, with details. Use the table above and send what you wrote down in step 2. "The site is down" gives a developer nothing to go on. "Checkout has returned a 500 error since 9:40, right after the payment plugin was updated" lets them start immediately.

Steps 5-7: while it's being fixed

Once the right person is on it, your job is to manage everything around the fix. This is where things tend to go sideways, because everyone wants to help at the same time.

5. Don't make it worse. Avoid restarting the server over and over, deleting files or restoring a backup before anyone knows the cause. Last night's backup can wipe out today's orders and sign-ups, and a restart can erase the log files (the system's record of what happened) your developer needs. Keep it to one person working in the system at a time. You want to know your backups can actually be restored before the bad day, and I cover how to check in my guide to web app backup strategy.
6. Tell customers and colleagues what's going on. A short note by email, on social media or inside the app beats silence. Say you know about the problem, that it's being worked on and when the next update will come. Give your support team the same message so customers don't hear three different stories. Don't promise a fix time until your developer has given you one.
7. Ask for a short write-up afterwards. Once the site is back, ask for a few lines in writing: what happened, why, what was done and what will stop it happening again. It doesn't take long to write, and it's the most useful document you'll have next time. If an update triggered the outage, it's also a good moment to ask how far behind the rest of the system is and why letting dependencies fall behind gets expensive.

Why some outages take 20 minutes and others take three days

The fix itself is rarely the slow part. Everything before it is: working out who has access to what, finding the code, understanding how the server is set up and checking whether there's a usable backup. A developer who has never seen your system will often spend most of the first stretch just getting their bearings.

Four things make the biggest difference:

• Access. Logins for the domain, hosting, code repository and third-party services live in a password manager your company owns.
• Monitoring. A tool spots the outage before your customers do and alerts someone who can act on it. I compare the options in my roundup of uptime monitoring tools for web apps.
• Familiarity. A developer who already knows the code and the server can go straight to the likely cause instead of starting from scratch.
• Tested backups. A backup is only worth something once someone has restored it successfully.

That's exactly what a maintenance agreement should guarantee. The hourly rate matters less than having it settled in advance who you contact, how quickly they respond, and that access and documentation are already in place. My checklist for a software maintenance agreement covers what a good one should include.

If you think the site has been hacked

Typical signs are pages or links you didn't create, redirects to spam, a browser or Google warning, or admin accounts you don't recognize. Step 5 applies twice over here: don't delete anything and don't reinstall the site yourself. The traces show how the attacker got in, and without them they often get back in the same way.

Ask your developer to lock down access, rotate passwords and API keys and preserve the logs before any cleanup starts. Change the password on your own email account too, if it's the one used to reset access to your hosting or domain.

If the system holds personal data, such as customer accounts, orders or a mailing list, you may be dealing with a personal data breach. Under Article 33 of the GDPR, the controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to put people's rights and freedoms at risk. In practice that means your national data protection authority. UK businesses report to the ICO, which also asks for notice within 72 hours where feasible. The clock keeps running over weekends.

When a freelance developer is the wrong call

Someone like me isn't always the fastest way out of an outage. In these situations, start somewhere else:

• If your site runs on Shopify, Wix, Squarespace or another hosted platform, the platform owns the servers. Contact their support and check their status page. An outside developer can't fix an outage on their side.
• If your host has a confirmed outage, no developer can make it go faster. Your job is to keep customers informed and wait it out.
• If you already have an agency or developer under contract, call them first, even if you're unhappy with them. A new developer needs access and context before they can help, and that costs time mid-outage. Switch later, once things are calm.
• If you need guaranteed round-the-clock cover, including nights and weekends in your own time zone, a provider with a 24/7 on-call team is a better fit than any solo developer, me included.
• If the domain simply expired, you can usually renew it yourself with your registrar in a few minutes.

I'm the best fit for custom-built systems in Laravel/PHP or JavaScript, especially when nobody knows the code anymore, or when you want things set up so the next outage is a short one.

Next steps: write your outage plan before you need it

The best time to write an outage plan is an ordinary Tuesday when everything works. Spend an hour on the checklist below and store the result somewhere more than one person can find it.

If you can't tick off most of these, your maintenance is effectively left to chance. If you'd like help putting them in place, here's how I handle maintenance and ongoing development of existing web apps.

Frequently asked questions

How long can my website be down before it hurts my Google rankings?+

A few hours of downtime rarely does lasting damage. Server errors make Google crawl your site more slowly, and pages that keep failing are eventually dropped from the index. If you urgently need to take the site offline for 1-2 days, Google's guidance on pausing a website recommends serving an informational error page with a 503 status code instead of your normal content. The shorter the outage, the better.

Will my hosting provider compensate me for downtime?+

Usually only to a limited extent. Many hosts promise a set uptime in their SLA (service level agreement), but compensation is typically a credit on your hosting bill, not cover for lost sales. On a €30 a month plan, that credit is small next to a day without orders. Read the terms before you choose a host. Protecting lost revenue is a matter for insurance and contracts, which an advisor should review.

Why is my site down for some people but not for others?+

Most often because people's devices aren't looking up your site in the same place. After a domain or hosting change, it can take anywhere from minutes to a day or more before every network picks up the new address. Mobile data, older browsers and cached files add to the mix. Test on both Wi-Fi and mobile data and send the results to your developer. If it only fails on certain devices, that's a different problem from an outage.

Is a maintenance retainer worth it if my site rarely goes down?+

It depends on what a day without the site costs you. For a small brochure site, having a developer you can call and pay by the hour may be enough. For an online store, customer portal or SaaS product where downtime means lost orders and unhappy customers, an agreement with monitoring and a known response time is usually cheaper than one long outage. Run the numbers: revenue per hour times the hours an unprepared outage can last.