Blog

On the status pages of OpenAI and Anthropic, many incidents pass through a “Monitoring” stage, where the company says a mitigation is in place and it is watching to confirm it held, before it posts “Resolved”. We read both companies’ public incident feeds and measured that stage. Most incidents were not affected by it much: the typical gap from the first “monitoring” update to “resolved” was about half an hour on both pages, and 29 of the 71 incidents we measured never had a monitoring update at all. But a few long monitoring stages carry a lot of the total, so an incident’s displayed length can say as much about when the company chose to close it as about how long users were affected.

Key takeaways

1. Atlassian, whose Statuspage software Anthropic’s page runs on, defines Monitoring as “We think we’ve found a solution and we’re monitoring it.” We did not find OpenAI’s own definition.
2. Coverage: 18 of OpenAI’s 21 resolved incidents had a monitoring stage, against 24 of Anthropic’s 50. Medians from the first “monitoring” update to resolved were 32 minutes (OpenAI) and 25.5 minutes (Anthropic).
3. Pooled across the incidents that had the stage, 75% of OpenAI’s open time (58% without its largest case) and 39% of Anthropic’s (35% without its largest) came after the first monitoring update. The medians per incident were 65% and 50%. The periods and sample sizes differ, so this is not a ranking.
4. A long bar can mean different things: OpenAI’s 45-hour Space Pages incident had 92% of its open time after the first monitoring update, while Anthropic’s 99-hour Windows incident never had a monitoring update at all.

Last reviewed 6 October 2026. We took a snapshot of OpenAI’s public incident feed (its 25 most recent incidents, started 15 September 23:50 UTC to 5 October 17:58 UTC; 21 were resolved and 4 still open, which we excluded) and Anthropic’s (its 50 most recent incidents, 25 July to 5 October, all resolved), and read Atlassian’s incident communication guide. All times are UTC. The two samples cover different periods and sizes. The per-incident data and the method are at the end, and an earlier version of this article had slightly different medians, because we took the upper middle value where there was an even count.

What do the four stages mean?

Atlassian’s guide to incident communication with Statuspage (retrieved 2026-10-05) lists four stages in order: “Investigating: We’ve been alerted, and we’re looking into a potential problem”; “Identified: We’re announcing that we’ve identified a problem”; “Monitoring: We think we’ve found a solution and we’re monitoring it”; and “Resolved: We’ve resolved the incident.” The same four status names appear in both providers’ feeds. Anthropic’s page states in its footer that it is powered by Atlassian Statuspage. We did not find OpenAI’s own definition of its stages, so we use Atlassian’s wording as the common reference and say so where it matters.

In that model, “Resolved” often follows “Monitoring”, but not always: on the two pages we measured, 29 of 71 incidents went to resolved without a monitoring update. Where there is one, the clock keeps running after the fix is announced. That time is real time on the page, but it is not necessarily time users were affected.

What we measured

The pooled share is our own calculation: for the incidents with a monitoring update, the minutes from that update to the resolved mark, summed, divided by those incidents’ total open minutes. It is a time-weighted figure, so long incidents dominate it. OpenAI’s pooled figure depends heavily on one incident, “Elevated errors in ChatGPT Space Pages”, which was open for 2,724 minutes and had 2,502 of them after its first monitoring update; that single case is about 63% of OpenAI’s pooled minutes after monitoring. We show the same leave-one-out for Anthropic, whose largest tail is “Delayed credits on the Claude Platform” (376 minutes open, 253 after). The per-incident medians are less sensitive to single cases, and they put the two providers closer together than the pooled figures do.

Three details affect how to read the shares. One OpenAI incident and two Anthropic incidents opened directly at the monitoring stage, so their tail is their whole open time, and dropping them barely changes the pooled shares (75.1% and 35.9%). A provider that is slower to post a monitoring update will, mechanically, show a lower share, so a low share does not mean less waiting after a fix. And the median gaps from the first post to the first monitoring post are measured only on incidents that had one, so they should not be read next to the median over all incidents. We would not read any of this as one provider being slower or more careful, because the samples differ in size and period and each company chooses when to post and when to close.

Two long incidents with different stage patterns

A table of minutes open treats a long incident as one thing, and the feeds show different stage patterns behind long bars. OpenAI’s Space Pages incident started on 30 September at 02:20 UTC, had its first monitoring update after about 223 minutes, and was marked resolved about 2,502 minutes later, roughly 41.7 hours. Over 90% of its open time came after the company first said a mitigation was in place. We cannot tell from the feed whether that stage was a real risk of recurrence, a slow close-out or something else.

Anthropic’s Claude Cowork on Windows incident was longer, 5,961 minutes from 10 September at 15:54 UTC, but its recorded stages are only Identified and Resolved, with no monitoring update. What the stages show is that Anthropic posted no monitoring update before it marked the incident resolved, after, per Anthropic, a Microsoft update shipped. They do not tell us how many users were affected during those roughly 99 hours.

Two examples from outside the sample, because they predate the feed window, show how a stage looks in practice. First, OpenAI’s 3 September incident, from its incident page converted to UTC, which we covered in our check of the Azure explanation: investigating at 14:43, “we have applied the mitigation and are monitoring the recovery” at 15:17, and resolved at 16:55. That is 34 minutes to mitigation and 98 minutes of monitoring, 74% of the 132 minutes. It is one incident, not corroboration of the pooled share. Second, in our ChatGPT Work Mode case study, three forum users reported tools working again from 20:11 UTC on 14 September, about seven hours before OpenAI marked the incident resolved at 03:11 UTC the next day. That incident had opened at the monitoring stage, with users in the same thread still reporting failures, so there the stage described the company’s belief and not the users’ experience.

What this means when you read a status page

• Duration is not downtime. The minutes between an incident’s first post and its resolved mark include any monitoring stage. Our comparison of the two providers’ incident records made the same point about totals.
• The error can run both ways. A resolved mark can come after users recover, as in the Work Mode example, and a first post can come after users were already affected, as the thread’s author said was the case there. Duration can overstate or understate impact.
• Read the stages as well as the end time. If an incident has a monitoring post, the gap from the first post to it shows when the company said a mitigation was in place, which is not necessarily when users stopped being affected. If it has none, a long duration says only that it stayed open.

What we could not verify

• The two samples are not comparable in size or period: OpenAI’s feed holds only its 25 most recent incidents, so we measured 21 over about three weeks, while Anthropic’s holds 50 over about ten weeks.
• We cannot tell how either company decides when to post a monitoring update or close an incident. A long monitoring stage may reflect sensible caution after a real risk of recurrence.
• We do not know how many users were affected during any stage, so we cannot say how much of the monitoring time involved real impact.
• We excluded OpenAI’s 4 incidents that were still open. They are probably among its longer ones, so the OpenAI figures may change once they close, by an amount we cannot know.
• We did not find OpenAI’s own definition of its stages. Atlassian’s applies to Anthropic’s page, and is only an assumed fit for OpenAI’s.
• We used each incident’s first “monitoring” update as the start of the stage. Some incidents posted several, and some may have mitigated the problem before the first.

How we researched this, and the data

On 5 and 6 October 2026 we read the public JSON incident feeds from OpenAI and Anthropic (retrieved 2026-10-06; neither had a new incident between our two reads). Each incident has a created_at time, a resolved_at time and a list of updates, each with a status and a display time. We took created_at as the start, resolved_at as the end, and the earliest update with the status “monitoring” as the start of the monitoring stage. Three updates on two OpenAI incidents are displayed 10 to 70 minutes before their incident’s own start, so we clamped any monitoring time to no earlier than the incident start. Minutes are rounded, so 223 and 2,502 add to 2,725, not 2,724. We checked the stage definitions against Atlassian’s published guide, and the calculations were done by a script rather than by hand.

The per-incident data behind every figure above, one row per resolved incident with its start, first status, minutes open, minutes to the first monitoring update and minutes after it, is in this CSV file (71 rows, snapshot of 6 October 2026). The live feeds roll forward, so the CSV is the record of what we measured.

Frequently asked questions