The right-hand sidebar on the homepage shows two numbers — outage reports in the last 24 hours, latency reports in the last 24 hours — plus a scrolling feed of the most recent submissions. It looks small. It is the most under-appreciated part of the dashboard.
This post is about what those numbers actually mean, what they correlate with, and the specific patterns that show up only because users are reporting in real time.
What the sidebar is
Three things, each kept deliberately small:
- Two count buttons — outage and latency reports in the last 24 hours, in UTC.
- A scrolling feed of the last reports, with timestamp, severity tag, and 80-character description.
- An hourly trend chart — collapsible, clickable from each count button — showing the last 24 hours bucketed into 1-hour bins.
Reports are anonymous. There is no account, no email, no identifier persisted with the submission. Each report is tagged with one of two categories — outage or latency — and a free-text description capped at 80 characters. Submissions are rate-limited to 10 per IP per 60 seconds and auto-deleted after 3 days.
The 80-character cap is intentional. We will explain that choice in another post. For now: it forces brevity, kills spam vectors, and makes the feed scannable in seconds.
What the sidebar tells you, and what it does not
The sidebar is leading-indicator data. It moves before the official Statuspage indicator does, because the path from “user notices something” to “user reports it” is shorter than the path from “Anthropic on-call sees alerts” to “incident is officially classified.”
In a typical week of background traffic, we see roughly:
- 0–3 outage reports per hour
- 0–5 latency reports per hour
These are baseline numbers. Some are users mistakenly reporting their own ISP issues, some are real but very localized, some are stale (a user submits 30 minutes after the symptom passed). Reading them individually is mostly useless.
What is useful is the rate. When a real incident hits, both numbers spike sharply. We have watched the outage count go from 1 to 40 in a 15-minute window, and we have watched it stay at 40 for an hour while the official Statuspage indicator was still green. That hour is the lead.
Three patterns worth knowing
Pattern 1 — sidebar spike + official page green = real but unacknowledged
The single most useful pattern. If the outage button suddenly shows 30+ reports in the last 24 hours and the official component grid is still all-green, an incident is happening that has not yet been escalated by Anthropic’s on-call. Possible reasons for the lag:
- Anthropic’s monitoring is region-scoped and the incident is currently affecting a region that under-triggers internal thresholds.
- The on-call has acknowledged the alert internally but the public post is in flight.
- The symptom is at a layer (e.g., specific feature, tool use, vision) that does not roll up into the top-level component status.
Whatever the reason, the practical implication is: trust the sidebar in the lead window. If you are operating a production system on top of the API and the sidebar is screaming, change behavior now — switch to a fallback model, slow your retries, queue traffic. Do not wait for the official confirmation.
Pattern 2 — sidebar quiet + official page red = narrow incident
The mirror image. The official component grid is amber or red, but the sidebar shows only 5–6 new reports. This means the incident is real but narrow — affecting a small subset of users, a specific region, or a specific feature.
If your traffic does not match the affected scope (read the incident text), you are likely fine. The lack of community noise is information: thousands of users are not currently broken.
Pattern 3 — sidebar steady spike with official page green for hours
The trickiest pattern. Reports keep flowing in at 5–10 per hour, sustained over half a day, but the official page never goes red. Two interpretations dominate:
- Aggregate noise spike — a popular creator tweeted “Claude is broken,” users flood in and report regardless of whether they personally experienced anything.
- Slow-burn degradation — a real but mild ongoing performance issue that does not cross Anthropic’s classification threshold for a public incident.
You can tell the two apart by reading the descriptions. Aggregate noise spikes have descriptions all over the place (“won’t load,” “slow,” “broken,” “down for me”). Slow-burn degradation has consistent descriptions (“API timeout,” “504 errors,” “Opus slow”) that all point at the same thing.
What we deliberately do not do
We do not curate, edit, or filter individual reports. This is a load-bearing choice.
A curated feed is no longer a community signal — it is a moderator’s interpretation of what they thought was real. Once you allow that, the question becomes “who picks?” and the answer immediately compromises the page. We instead let the rate-limit (10 per IP per 60 seconds) and the 80-character cap absorb most of the spam, accept that some reports will be off-topic or misattributed, and trust readers to read the rate rather than individual entries.
We also do not amplify reports outside the dashboard. They do not leave the page. We do not have a Twitter account that auto-posts community reports during outages, because that would create incentive to spam the sidebar to drive Twitter exposure. Volunteer signal works only when the volunteer cannot personally benefit from spamming.
Finally, we do not cross-reference reports with the latency widget or the Statuspage indicator to “filter out noise.” All three are independent signals and the user gets to combine them in their head. A dashboard that pre-correlates would be hiding the disagreements between sources, which are themselves the most informative thing on the page.
Reading the trend chart
Click either count button and the trend chart drops down. Each bar is one hour, bucketed in UTC. Outage and latency render separately — clicking the outage button shows the outage trend, clicking latency shows latency.
Patterns in the chart that mean something:
- Sharp spike, sharp decline. A real, transient incident. Often correlates with an official Statuspage incident in the same window.
- Rolling rise across hours. Slow-burn degradation. Worth checking the latency widget and reading recent incident text.
- Spike with a long tail. An outage was followed by a recovery period during which users keep reporting because they remember the bad experience.
- Constant background hum. Normal weekday traffic. Most cells under 5.
The chart is intentionally low-fidelity — 24 hourly bins, no smoothing, no SVG complexity beyond a path and a fill. It is meant to answer “is this a spike or is this normal” in less than a second.
Why we keep reports for only three days
Two reasons. Privacy: reports are anonymous, but a 90-day archive of anonymous-but-precisely-timestamped reports starts to be useful for de-anonymization across data sources we cannot anticipate. Three days minimizes the temptation. Operational: longer windows shift the natural reading of the page from “what is happening now” to “what happened recently,” and the page is not built for the latter — the official Statuspage’s incident archive is the right tool for historical research.
After three days, individual reports drop out, but the count buckets used for the trend chart are persisted in aggregate form. We can tell you that hour X two weeks ago had 12 outage reports, but we no longer have the descriptions.
What this signal cannot do
The sidebar will not tell you exactly what is broken — only that something is. It will not tell you whether a recovery has reached your region. It will not give you a uniform global view, because reporting volume is biased toward the regions and time zones where the dashboard’s audience is most concentrated. It is a useful early warning, not a complete picture.
It is most informative read in combination with the latency widget (independent of user behavior) and the Statuspage component grid (Anthropic’s official assessment). The three signals disagree with each other often enough to make their combination informative — when all three say the same thing, you have certainty; when they disagree, you have learned something about the lag between user experience and provider acknowledgment.
That lag, more than anything else, is what the sidebar exists to surface.