Platform outages: common questions and clear answers

When a platform stops working, the first thing you lose is the ability to find out why. The platform's own channels are the ones that are down, the people who know are busy, and everyone else is guessing in public. This page is built around the questions people actually ask in that hour, and around the one preparation that changes the answers: a small monitor of your own, running before anything breaks.

Nothing here describes any particular incident anywhere. Outages at named companies are the least useful thing to study, because the next one will be different. The layers where they happen are the same every time.

What to take away

"Down" can originate in five different layers, and the fix, the duration and what it means for you differ by layer. Locating the layer is the whole diagnosis.
Your own monitor answers the question a status page cannot: is it down for me, from here, on the paths I depend on, right now.
During an outage, record and wait. Afterwards, annotate. Republishing into an outage is the one action that reliably makes things worse.

Where an outage can live

Layer	What is failing	How it looks from your side	Typical duration	What it means for your material
Your device or network	Your connection, DNS resolver, browser state	Only you, or only your office, cannot get in	Minutes	Nothing. Nobody else is affected
The edge	The content network or name resolution in front of the platform	Some regions fail, others fine; static pages load, actions fail	Minutes to an hour	Delivery is impaired for part of the audience
The front door	Login, the main pages, the app's opening screen	Everyone gets errors; the platform is "down" in the headline sense	Under an hour to several	Nothing reaches anyone; your numbers show a hole
A subsystem	Uploads, notifications, search, messaging, analytics	The site works but one thing does not	Hours, sometimes longer	Depends entirely on which subsystem
A regional segment	One data center or one country's routing	Fine here, broken there	Variable	Your audience in one place is cut off; the rest carry on

The layers are listed from nearest to furthest, and that is the order to check in. The nearest ones are the most common and the cheapest to rule out. A single failing component that takes everything else with it is the textbook single point of failure, and large platforms spend a great deal removing them, which is why full front-door outages are rarer than subsystem ones and why "the whole thing is down" is usually an overstatement of a subsystem failure that happens to be in the path you use.

Down for me, or down for everyone?

You cannot answer this from one place. What you can do is triangulate.

Try a different network. A phone off its wireless connection is a different route.
Try a different action. Reading works and posting fails is a subsystem, not the front door.
Try a different region, if you have a way to. A colleague elsewhere is the cheapest instrument.
Look at the platform's status page, with the understanding that it lags and understates. It reports what the operator has confirmed, at the granularity the operator chose, and nothing else.
Look at whether people you do not know are reporting the same symptom. Volume of complaint is a crude but fast signal that the front door or the edge is affected.

Build your own monitor

Every operator in the picture above could see, at a glance, which lines were live and which were not. That is all a monitor is for. A monitor is a script that does the things you depend on, from somewhere that is not your desk, on a schedule, and records what happened. The general practice is called synthetic monitoring, and the version you need is small.

What to probe. One probe per thing you depend on, no more.

Fetch a public page of yours on the platform and check that it returns and contains something you expect.
Fetch a public page from a second location if you can, so the edge layer becomes visible.
If there is an API you use, call the cheapest read-only endpoint.
If you publish on a schedule, check that the last scheduled item actually appeared.

How often. Every few minutes for the public fetch; hourly for anything that costs the platform something. Faster than that and you become the problem.

What to record. Time, which probe, success or failure, the response time, and the first line of any error. The response time series is the underrated part: most incidents begin as slowness, and a slow week before a failure tells you more than the failure.

Where to run it. Anywhere that is not your own network, and ideally in two places. A free tier of almost any hosting is enough for a script this size.

When to alert. After two consecutive failures, not one. One failure is noise. Two in a row from two places is an incident.

That is the whole build. Its value is not that it tells you the platform is down; the internet will tell you that. Its value is the log, which is what lets you do the thing in the next section.

During and after

During: stop. Do not republish. A failed publish during an outage may have succeeded silently; a second attempt produces duplicates, and duplicates have consequences of their own once constraints outside scoring notice them. Record the time you first saw the problem and each thing you tried. Hold scheduled items if you can, or accept that they will land into a quiet period, where the thin early response can be read by a recommender as weak evidence about items that were never really shown.

After: mark the window on your analytics and in the register you keep for platform changes. Every metric for those hours is contaminated, and if you do not annotate it now, in three months the dip will look like a ranking change. This is the most common way an outage does lasting damage: not the hours lost, but the false explanation adopted afterwards. The order in which to consider explanations for any drop is in what forces a feed to behave as it does, and an unannotated outage lands you at the wrong end of that list.

Then check whether anything of yours published during the window is duplicated, missing, or stuck in a half-published state, and fix that before you do anything else.

Common questions

The status page says everything is operational but I cannot log in. Who is right?

Both, possibly. Status pages report what the operator has confirmed, at the granularity the operator chose. Your monitor and a second network answer your question; the status page answers theirs.

How long should I wait before assuming it is on my end?

If two other routes work and yours does not, it is on your end now. If nothing works from anywhere, wait, and let the monitor keep the log while you do something else.

My numbers dropped on a day with no outage I know of. Could it have been a partial one?

Yes, and this is exactly what the monitor's response time series is for. A regional or subsystem incident that never reached a status page shows up as a slow, failing patch in your own log.

Should I move platforms after a bad outage?

Outages are a property of every platform. What you should do is make sure no single platform is the only place your audience can find you, which is a decision about dependence rather than about any one incident.