Rules
Part of Platform outages: down for you or down for everyone, and how to tell
Platform outage or algorithm change: triage a traffic drop
Platform outages updates 2027 can't be predicted, so use this order to triage a traffic drop and separate a real outage from an algorithm change.
Traffic falls off a cliff and the first thing said in the room is usually "the algorithm changed." It is the worst opening hypothesis available. It is close to unfalsifiable, it blames nobody present, and there is always an update somewhere to point at. Meanwhile the four cheaper explanations sit unchecked.
This page sets out the order to check things in when a platform outage or an algorithm change is suspected, rather than trying to list platform outages updates 2027 in advance: cheapest and most likely first, so that a ranking change is what you conclude after eliminating the alternatives rather than what you assume before starting.
What to take away
- Work up the ladder from cheap and common to expensive and rare. Most drops are resolved in the first two rungs.
- Resolved on a status record does not mean recovered in your data. Backlogs clear later, and some never do.
- If you reach the top rung, write down what a ranking change would have to look like before you decide it was one.
The order to check in
| Rung | The question | Cost | What a positive looks like |
|---|---|---|---|
| 1 | Is the service actually degraded? | Minutes | Errors, timeouts or a partial dip that matches a published incident window |
| 2 | Is my measurement broken? | Under an hour | The drop is in one report and not in the server logs |
| 3 | Did we change something? | Under an hour with a deploy log | The date lines up with a release, a rule or a migration |
| 4 | Is it the calendar? | Minutes with last year's data | The same shape appears in the same week of previous years |
| 5 | Did somebody else move? | Hours | The loss is concentrated in a few topics, not spread across everything |
| 6 | Did the system change? | Days | Nothing above explains it and the shape is consistent across the checks |
Rung one is minutes of work if you already run a probe of your own, and the layers an outage can live in is the map it checks against.
That check is minutes of work for the platforms most teams depend on. Meta's status page covers Facebook, Instagram and WhatsApp, X, TikTok and YouTube publish their own, and a crowd-report site like Downdetector shows within minutes whether other people lost the same thing at the same time.
Order to check in
- 1. Is the service actually degraded?
- 2. Is my measurement broken?
- 3. Did we change something?
- 4. Is it the calendar?
- 5. Did somebody else move?
- 6. Did the system change?
Rung two catches more drops than most teams expect. Drops include a tag stopped firing on one template, a consent prompt changed its default, a date range with a partial day, and a filter saved last week.
A redirect dropped the referrer, and a sampling threshold crossed as volume grew.
Every one of those produces a clean, alarming line on a chart while the actual traffic is unchanged. Comparing the suspect report against a second source of truth, usually raw server logs, settles it quickly and is the highest-value hour in the whole sequence.
Reading a degradation properly
Full outages are the easy case: everything stops, somebody announces it, and it comes back.
Full outage vs partial degradation
Full outage
- Shape
- Hole
- Duration
- Minutes
- Looks like
- Obvious stop
- Detection
- Announced
- Symptom site
- Named component
Partial degradation
- Shape
- Dip
- Duration
- Hours
- Looks like
- Ranking change
- Detection
- Often unnoticed
- Symptom site
- Unrelated component
The awkward case is partial degradation, where one component is slow or one region is affected and the rest of the system works. That produces a dip rather than a hole, over hours rather than minutes, and looks more like a ranking change than a real outage.
Partial failures also spread. A queue backs up, a dependent service times out, retries multiply the load, and the visible symptom appears somewhere unrelated to the origin. That is an ordinary cascading failure, and its practical consequence for you is that the component named in an incident note is often not the component whose behavior you noticed.
Two things to hold onto when reading incident records. The stated start time is when detection happened, not when the behavior started, so effects can precede the window.
And resolved means the fault is fixed, not that every queued item has been processed, so your numbers may recover on a different schedule from the status record. What a status channel confirms is narrow, which is why it is worth comparing it against your own probe before ruling the outage in or out.
Separating the remaining causes
Once availability and measurement are cleared, three explanations remain and they are told apart by shape and scope rather than by size.
Telling remaining causes apart
Own change: on a date you can name, exactly the pages you touched?
Check deploy log, crawl directives, canonicals, redirects
Seasonal move: same week of prior years, whole category?
- Your own change shows up on a date you can name, usually affecting exactly the set of pages you touched. Check the deploy log before theorising, and check crawl directives, canonical tags and redirect rules specifically, because those fail silently and broadly.
- A seasonal move shows up in the same week of prior years, affects your whole category, and is visible to your competitors too. The test is one query against last year's data, and it is worth running before anything else expensive.
- A competitor's move is concentrated. If you lost across every topic evenly, nobody displaced you; something structural happened. If you lost in four topics and held everywhere else, somebody arrived in those four.
A genuine ranking change is what is left, and even then it deserves a prediction rather than a label. Write down which pages should be affected and which should not, then check. If the pattern does not match, you have named the wrong cause and you will spend the next month fixing the wrong thing.
Write the prediction and the result into the same file you use for incidents; the guide to handling an incident sets out that record. The discipline here is ordinary root cause analysis: keep asking what would have to be true, and stop when the answer is checkable.
Why the wrong diagnosis is so attractive
Because it is comfortable and because it cannot be disproved. Nobody has to admit a mistake, no process has to change, and the story survives any evidence. That is exactly what makes it dangerous as a first answer and reasonable as a last one.
The practical cost is not the wrong belief. It is that a team which concludes "the algorithm" stops looking, and whatever actually caused the drop stays in place until it causes the next one.
A dated record of what you checked and ruled out is what stops the same investigation being run from scratch every quarter. Having it ready before the next drop, rather than reconstructed after it, is what makes the difference.
Common questions
Nothing shows on the official status record. Does that mean nothing happened?
No. Status records cover what the provider has detected and decided to publish, and partial or regional problems often never appear. Absence is weak evidence, not proof.
How long should I wait before investigating?
Long enough to know it is not a single bad hour, short enough that the logs are still there. A day is usually right. The exception is a suspected measurement fault, which is worth checking immediately because the fix stops you losing more data.
Everyone else is reporting the same thing on the same day. Is that enough?
It is good evidence that something external happened and poor evidence about what. The reporting is self-selected toward people who lost traffic, so it will always look worse and more universal than it is. Your own log of the window is better evidence: the timestamp, the errors or timeouts you saw, and the pages, regions or devices they hit are what make it usable later.
Should I roll back my recent changes to be safe?
Only if a specific change is a plausible cause. Blanket rollbacks destroy the one clean thing you had, which was a dated list of what was different, and they make the next investigation harder rather than easier.
