Each component on the homepage has a strip of thirty small bars. Most readers glance at them, see “mostly green,” and move on. There is more information in those thirty squares than the glance captures. This is a guide to reading them properly.
The grammar
Each bar represents one calendar day, in UTC, going from 30 days ago on the far left to today on the far right. The color of each bar encodes the worst event that touched the component on that day:
- Green — no outage and no degradation that day.
- Amber — at least one
minorimpact incident touched the component, but nomajororcritical. - Red — at least one
majororcriticalincident touched the component.
That is the full color taxonomy. There is no fourth color, no gradient, no opacity for severity. We chose three categorical states because the distinction that matters to users is “should I treat that day as a bad day” — which is a yes/no/maybe question, not a continuous one.
The shape of the bar is uniform. A tall green bar is identical to a short green bar; we do not vary height by event count or duration. The bar is a categorical dot, not a histogram.
The percentage next to it
To the right of the strip is a percentage — “99.86% uptime over 30 days.” This is the simple arithmetic mean of the per-day uptime values across all 30 days, calculated using the interval-merge math we walk through elsewhere.
A few worked intuitions:
- 30 perfect days = 100.00%.
- 29 perfect days, 1 day with a 90-minute
majorincident = (29 + (1 - 90/1440)) / 30 = (29 + 0.9375) / 30 = 99.79%. - 29 perfect days, 1 day with a 60-minute
minorincident = same math, slightly milder = 99.86%. - All 30 days with an average of 30 minutes of
minordaily (which would be a terrible month) = (30 × (1 - 30/1440)) / 30 = 97.92%.
The math is conservative. A single bad day moves the number visibly. We chose the strict version because it tracks user experience more honestly than the marketing math; we go into why at length.
Today’s bar is special
The rightmost bar — today — does not represent a full day’s data. The day is still in progress. We compute its uptime using elapsed seconds since midnight UTC, not the full 86,400.
This avoids the failure mode where the page reads 99.999% at 00:01 because no time has passed and no downtime has happened, then drops to 99.5% at noon because of a 2-hour incident the previous evening. With the elapsed-seconds rule, today’s bar reflects only what has happened today, scaled to today’s actual elapsed time.
In practice this means today’s color flickers more than older bars. Five minutes after a major incident starts, today’s bar is bright red. Two hours into recovery, today’s bar may shift back toward amber as the proportion of healthy time grows. By the next UTC midnight, today’s bar is finalized and never changes again.
If you are trying to answer “what just happened today,” read the active incident cards above the component grid, not today’s bar. Today’s bar is a summary, finalized only at midnight UTC.
Patterns that mean something
A few common visual patterns in the 30-bar strip and what they typically mean:
A long run of green broken by a single red
The most common pattern. One incident a couple weeks ago, everything else fine. Total uptime in the 99.7–99.9% range. This is what a healthy month looks like for a mature service.
Two reds in close succession (within a few days)
Worth noting. Could be two unrelated incidents. Could be a recurrence — a fix that did not fully take. Reading the historical events feed below the component grid will usually disambiguate.
A red day adjacent to today’s amber
Often a long incident that crossed midnight UTC. The math splits the incident across two days according to the actual time spent in each, so the bar might show red yesterday and amber today even though it was the same event. Reading the incident’s start and end times in the historical feed clarifies.
Amber for several consecutive days, no red
A pattern of repeated minor incidents — could be sustained low-grade degradation, could be cumulative routine maintenance. The 30-day uptime number stays high (because each day individually is mostly fine) but the visual pattern is informative.
A solid red block of multiple days
Rare. Either an unusual sustained outage or — more often — a misclassified incident where Anthropic’s resolved_at got pushed forward without the underlying issue being fixed, so our overlap math attributed downtime to days it should not have. We have not had to correct this on this site, but it is the failure mode to watch for.
What the bars do not encode
Several things deliberately not encoded in the bar visualization:
- Severity gradient inside red. A 2-hour
majorincident and a 30-minutecriticalincident both produce a red day. The bar does not let you tell them apart. - Number of incidents. A day with three
majorincidents looks identical to a day with one. The percentage at the right reflects the total downtime; the bar reflects only the worst category. - Affected scope. A
majorincident that affected only US users still produces a red bar, identical to amajorincident that affected everyone. - Time of day. A 2 AM UTC outage and a noon UTC outage are colored identically, even though they affect very different audiences.
If you want any of those dimensions, the historical events feed below the grid carries the per-incident detail. The bars are deliberately compressed.
Why thirty days
Not arbitrary. Most public uptime SLAs are denominated in 30-day windows; matching that convention makes the number directly comparable to the number a contract or a marketing page might quote. Going shorter (7 or 14 days) hides recent-but-relevant incidents. Going longer (60 or 90 days) tends to mask the freshness of recent issues — a mediocre last week disappears into a great prior month.
We chose 30 days because it is the largest window where each individual bar is still meaningful at a glance, and the smallest window that catches “did this thing have a bad month.”
The strip as a reading exercise
Spend 30 seconds reading the bars on a normal day. Note what mostly-green looks like, where the occasional amber falls, how the percentage scales with the bar pattern. That is the calibration. When you arrive on the page during an actual incident, the strip becomes informative — you can immediately see whether today’s red is part of a bad week or a one-off, whether the affected component has had recurring issues, and how the current number compares to its recent envelope.
The bars are doing more work than they look like. They are a thirty-day visual log compressed into thirty pixels per row. Worth the half-minute of reading.