Status tracking: facts, examples and trends for 2027

A status page is a document written by the operator of a service, about that service, during the worst hour of the operator's week. Everything you need to know about how to read one follows from that sentence. It is honest within limits, late by construction, and scoped to what the operator has confirmed rather than to what you are experiencing. Tracking status well means reading it for what it is, and keeping a record of your own beside it.

What to take away

• A status page reports confirmed, component-level, operator-declared state. It does not report partial degradation, regional trouble, account-level problems, or anything about ranking.
• Three instruments see three different things: the status page, your own probe, and your own metrics. None substitutes for another, and a good record keeps all three in one row.
• The record's value arrives months later, when a dip in a chart needs explaining and the status page's history has been tidied.

How a status page gets written

Somewhere inside the operator, an alert fires. Someone decides it is real. Someone decides it is worth declaring. Someone chooses which of the listed components to mark and which severity word to use. Someone writes a sentence that must be true, not alarming, and legally safe. Then it is posted.

Every step in that chain delays and narrows the message. Automated components exist, and some pages flip a component on a threshold with no human in the loop, but the written updates that people actually read are still authored, and authored under pressure. The incentive at each step runs toward declaring less and later, not from dishonesty but because declaring costs something and un-declaring costs more.

The published availability figure is a further layer. It is usually defined by the operator's service level agreement, which specifies what counts as down, and the definition matters more than the number. A month can show a high uptime percentage while a subsystem you depend on failed for hours, if that subsystem is not in the definition.

What it tells you and what it does not

It tells you	It does not tell you
That the operator has confirmed a problem in a named component	That a problem you are seeing exists, if the operator has not confirmed it
Roughly when the operator noticed and when they consider it resolved	When it actually started, which is usually earlier
Which broad component is affected	Whether your region, your account type, or your specific path is affected
That a fix is being worked on	What broke, in any detail you could act on
A history of declared incidents	A history of undeclared ones, which is longer
Whether the machinery is running	Anything about what the machinery chooses to show, which is never a status page matter

The last row deserves emphasis because it is the one people most want. A drop in reach is not an outage and will never appear on a status page, however real it is. The status page is about whether the machinery runs, not about what it chooses to show; the inputs behind that choice are the subject of what a ranking input can and cannot be, and the order in which to check a reach drop is in what forces a feed to behave as it does.

Three instruments

Keep them apart, because each is blind where the others see.

• The status page sees what the operator confirmed. It is authoritative about that and silent about everything else.
• Your own probe sees whether the paths you depend on work, from where you run it, right now. Building one is a short job, described in how to monitor a platform yourself. It is authoritative about your experience and silent about cause.
• Your own metrics see what happened to your material. They lag, they are contaminated by everything else that day, and they are the only one of the three that measures what you actually care about.

A useful incident is one where all three agree. A useful puzzle is one where they do not: the probe failed, the status page was green, and the metrics dipped. That combination is the signature of a partial or regional problem the operator never declared, and it is far more common than a declared full outage.

The record

One row per incident you noticed, with these columns. A spreadsheet is enough.

1. Start, as you saw it. The first timestamp from your probe or your own experience. Not the status page's declared start.
2. Start, as declared. The status page's time, if there was one. The gap between columns one and two is a number worth tracking over time.
3. Component, as declared. The operator's own label, verbatim.
4. Symptom, as experienced. What actually failed for you, in your own words.
5. Scope. Everyone, your region, your account, or unknown.
6. End, both ways. When your probe recovered, and when the page said resolved.
7. Metrics affected. Which of your numbers show a mark for the window.
8. Note for future you. One sentence. "Do not read the dip in this week as anything else."

The eighth column is the reason to keep the record. Declared incident histories get consolidated and trimmed, and your own memory of a bad afternoon fades in weeks. Six months later a chart shows a dent and someone asks what happened. The record answers in one line; without it, the dent becomes evidence for whatever theory is fashionable that month.

Three patterns to recognize

None of these describes any real event. Each is a shape that recurs.

The green outage. Probe failing from two locations, status page unchanged, complaints visible elsewhere. Usually the edge or a region. Log it with scope unknown, and expect no declaration.

The late declaration. Status page marks a component degraded an hour after your probe first failed, and marks it resolved before your probe recovers. The gap columns capture this. Over a year, the average gap is a fact about the operator you can rely on.

The phantom. Your metrics dip, probe clean, status clean. Not an outage. Go to the reach checklist, and do not let it into the incident record, where it would poison the pattern.

Where this is heading

Status pages are becoming more granular and more automated, which is an improvement, and they are becoming more polished, which is not always one. A page that is a product in its own right, with a design team, is a page that is being read by customers and written accordingly. Expect the declared history to get cleaner and your own record to get more valuable in step. The trend in how platforms present themselves generally, of which this is a small instance, is described in the three layers of platform change.

Common questions

Should I subscribe to status notifications?

Yes, and route them to somewhere you will see them but not somewhere they will interrupt you. They are one column of the record, not an alarm.

The status history shows a clean quarter. Does that mean nothing happened?

It means nothing was declared at the level the page reports. Your probe log for the same quarter is the other half of the answer.

How do I use the record with a client or a team?

As the annotation layer on every chart. Each row becomes a marker on the timeline, and the discussion moves from "what happened here" to "we know what happened here, so what happened over there".

Is it worth tracking status for a platform I barely use?

Track the ones where an undeclared incident would cost you something you could not otherwise explain. For the rest, the public reporting is enough.