What to do when a website is down
Confirm it, work out roughly how long, protect anything involving money, and then stop. The most valuable skill during someone else’s outage is knowing which of your instincts to ignore.
Confirm it, work out roughly how long, protect anything involving money, and then stop. The most valuable skill during someone else’s outage is knowing which of your instincts to ignore.
An outage is one of the few technical situations where doing less is measurably better than doing more. Almost every action available to you is either neutral or harmful, and the harmful ones are the ones that feel most productive.
Here is the order that actually helps.
Before touching anything, establish whether the site is reachable from a network that is not yours. Switch to mobile data, or run a check from our servers. This is not a formality - It decides everything that follows, and getting it wrong means spending the next twenty minutes fixing equipment that was never broken.
If the site responds from elsewhere, the problem is local and there is a specific order for working through it. If it does not, continue here.
Three sources, in this order of reliability.
The provider's own status page, if one exists. Authoritative, and usually slow - Companies confirm incidents after diagnosis, not on suspicion. A component-level page is far more useful than a single overall banner, because a degraded component with a green banner tells you exactly what is broken.
Independent monitoring. Whether anything can reach the service from outside, and whether it has been down before. What is currently failing our checks is the fast version of this.
User reports. Unverified, but they lead everything else during a partial outage, and the problem breakdown tells you which feature is affected. What people are reporting right now.
If several unrelated services are failing together, look at the layer underneath - A cloud region, a CDN, a DNS provider. That changes your estimate of duration considerably.
This is the part that matters, and it is where real losses happen.
Do not retry a payment or transfer. If a transaction appears to fail during an outage, the money may already have moved - The failure is frequently in the notification path, not the payment path. Retrying is the single most common cause of duplicate charges and duplicate transfers. Instant transfer networks are the worst case, because those transfers are effectively irreversible.
Instead: Screenshot what you see, including the time. Check your account's transaction history rather than the displayed balance - During an incident the balance is often a stale cached figure while the ledger is correct. Wait, and check again in an hour before doing anything.
If you are trading, be aware that stale quotes with a working order path are the dangerous combination: Orders execute against a market you cannot see accurately. Most brokerages will tell you to stand down during a data incident, and they are right.
If the outage affects work - A missed deadline on a learning platform, a failed submission, a booking that would not complete - Capture the evidence now, with a visible timestamp, before the page changes. Institutions and companies are generally reasonable about confirmed platform outages, but only if the claim is specific: Which page, what error, what time.
Our recorded outage log exists partly for this: It gives an independent, dated record of when a service stopped answering, which is more useful in a dispute than a screenshot alone.
Three things people do next that reliably make it worse.
Clearing app data or reinstalling. Some apps store content locally that has not synced yet, and clearing data destroys it permanently. Snapchat Memories is the notorious example: The app's own support advice during problems has historically been to clear the cache, and people have lost years of unsynced photos following it during an outage that had nothing to do with their device.
Changing network settings. Switching DNS servers, resetting the network stack, reconfiguring the router. If you have confirmed the site is unreachable from an independent network, none of this can help, and you will be undoing it for the next week.
Refreshing repeatedly. It adds load to a system that is already saturated and slows the recovery for everyone, including you. If the service is queueing, aggressive refreshing may also push you further back.
Better than checking every five minutes. Most status pages offer email or webhook subscriptions. On this site you can press Notify me when it recovers on any status page, and the RSS feed carries incidents as they close.
If you are responsible for telling other people - A team, customers, a class - Send one message early saying what is broken, what you know, and when you will next update. Then actually update at that time, even with nothing new. The absence of updates is what turns an outage into a crisis for the people waiting on it.
For consumer services, compensation is rare and discretionary, but it exists: Game platforms frequently grant in-game currency after significant downtime, and subscription services sometimes extend billing periods if asked. Asking costs nothing.
For business services with a service level agreement, credits are almost never automatic. You have to notice, calculate and claim, usually within a defined window, and the credit is a percentage of the fee rather than of your losses. What an SLA actually promises goes through the arithmetic, and it is less than most people assume.
If the outage affected something with a deadline, contact the institution rather than the platform. Universities and employers deal with platform outages regularly and are generally willing to accommodate them when the claim is specific and timestamped.
No. The money may already have moved while the confirmation failed to arrive, and retrying is the most common cause of duplicate charges. Screenshot what you see, check your transaction history rather than the displayed balance, and wait an hour before trying again.
Not necessarily. Some apps hold content locally that has not synced yet, and clearing data destroys it permanently. Confirm the platform is genuinely down before deleting anything - A platform outage is never fixed by reinstalling the client.
For consumer services, occasionally and at the provider's discretion - game platforms often grant in-game currency, and subscription services sometimes extend a billing period if asked. For business services with an SLA, credits exist but are rarely automatic: You have to calculate and claim them within a defined window.
Screenshot the error with the time visible, and note the exact page. An independent record helps too - Our recorded outage log gives a dated, third-party account of when a service stopped answering, which is more persuasive than a screenshot on its own.
A practical order of tests for working out whether a website is genuinely down or the problem is on your side - And what each result rules out.
Typical outage durations by cause, why most incidents resolve in minutes, and the warning signs that an outage is going to be a long one.
What service level agreements really commit a provider to, how credits are calculated and claimed, and the exclusions that matter most.
The real causes of website outages - Configuration pushes, BGP withdrawals, expired certificates and dependency cascades.