Blog

A status page is only useful if its times roughly match what users experienced, and OpenAI gives us a way to check one half of that. For 15 incidents it published a write-up that states when impact began and when service recovered, and each of those incidents also has a status-page timeline. We compared the two. In all 15, OpenAI’s first status post came after the start its own write-up gives, by a median of 20 minutes and between 7 and 75. The incident was marked resolved within 30 minutes of the write-up’s stated end in 8 and more than 30 minutes later in 7, in one case by about 22 hours. Neither source measures how many users were affected, so this compares two company accounts and is not a verdict on either.

Key takeaways

1. In all 15 incidents, OpenAI’s first status post came after the impact start its own write-up states: a median of 20 minutes later, between 7 and 75. In two of them, 3 September and 14 July, the page shows a start equal to the write-up’s start, because OpenAI set the displayed start 15 and 19 minutes before it actually posted.
2. The incident was marked resolved within 30 minutes of the write-up’s stated end in 8 of 15 and more than 30 minutes after it in 7 (by 35 to 1,327 minutes). None was resolved more than 30 minutes early. The write-up’s end sometimes means mitigation or the end of residual problems, and “resolved” normally follows a monitoring stage, so some of the gap is by design.
3. Excluding 23 July, the displayed time totals 1,413 minutes against 1,207 stated, about 17% more, with individual incidents ranging from 0.23 to 3.6 times. The 23 July incident alone shows 1,677 minutes against a stated 402.
4. Read the status page as OpenAI’s real-time account, which began a median 20 minutes after the impact start OpenAI gives in its write-up, and the write-up as its retrospective account.

Last reviewed 8 October 2026. Status-page times come from each incident’s own page on status.openai.com, retrieved 8 October. The write-ups were retrieved between 6 and 8 October and we did not re-check them for later edits. Write-up times are in Pacific time and described as approximate, and we converted them to UTC by adding seven hours (PDT). Where the comparison depends on how we matched them, we say so.

What did we compare?

OpenAI has linked a write-up from 17 of the 111 incidents on its status page since 9 July, covering 16 distinct write-ups (our dataset of those incidents has the details). Each write-up states an impact window in its summary, for example “between approximately 3:33 p.m. PDT and 4:47 p.m. PDT”. We matched each one to its incident and compared three things: when OpenAI first posted the incident against the write-up’s stated start, when the status page’s first “resolved” update was posted against the write-up’s stated end, and the two total durations.

We used 15 incidents. Two of the 17 were left out because their write-ups describe more than one separate impact period that we could not map onto a single window: the 21 July sign-in incident (two periods the same day) and the 21 July image-generation incident (a second period six days later, on 27 July). The 25 July write-up covers two incidents on the status page, each matching one of its two periods, so we compared each with its own period. The two left-out incidents are summarised below, so you can see whether leaving them out changes the picture.

The write-up’s “end” is not always the same event. For most it is recovery. For 3 September it is mitigation, and the write-up says returning traffic overloaded some services and prolonged recovery. For 29 September it is the end of residual degradation, after most customer-facing impact was mitigated earlier. The status page’s end is always its first “resolved” update, which normally follows a monitoring stage, so a positive gap at the end partly reflects that stage by design.

How do the times compare, incident by incident?

The last two numeric columns are differences in minutes. A positive number in the fourth means OpenAI’s first post came after the write-up’s stated start, and a positive number in the fifth means its “resolved” update came after the write-up’s stated end. The 25 July second period is the only negative value, by one minute.

What stands out?

The first post comes after the start OpenAI gives. In all 15 incidents the first post is later than the write-up’s stated start, by 7 to 75 minutes with a median of 20. In 13 of them the page’s displayed start equals the time of the first post. In the other two, 3 September and 14 July, the page shows an earlier start, 15 and 19 minutes before the incident was published, and in both the displayed start matches the write-up’s start to the minute. We read that as OpenAI setting the displayed start to when impact began, which is a reasonable choice and also means the displayed start is not always when users were first told. Across all 111 incidents in our dataset, 11 (10%) show a displayed start earlier than the posting time, by 15 to 302 minutes.

It is usually resolved soon after the write-up’s recovery, and sometimes much later. Eight incidents were resolved within 30 minutes of the write-up’s end. The other seven were resolved 35 to 1,327 minutes after it, and five of them more than an hour after: 23 July (1,327), 19 July (120), 3 September (95), the first 25 July period (78) and 30 July (74). Some of that is the monitoring stage, which is built into how “resolved” works. For 3 September the page posted “mitigation applied” at 15:17 UTC, three minutes before the write-up’s 15:20, and then stayed in monitoring until 16:55, a stage we described in our study of what “resolved” means. For 31 August Free and Go, the write-up itself says OpenAI continued monitoring and marked the public incident resolved at 6:00 p.m. PDT, which is when the page closed.

One incident dominates the totals. The 23 July status entry is open for 1,677 minutes against a stated impact of 402. The incident page shows further updates on 24 July, which went back to “investigating” after earlier “monitoring” updates, with no earlier “resolved” update. The write-up does not mention them, so we do not know what the extra time covered. Without that incident the totals differ much less, 1,413 minutes against 1,207. Across all 15, displayed time was more than 10 minutes longer than the stated impact in 7 incidents, more than 10 minutes shorter in 5, and within 10 minutes in 3. The ratio of displayed to stated time runs from 0.23 (2 September Work Mode: 6 minutes against 26) to 4.17 (23 July), with a median of 1.04.

Does leaving out two incidents change the picture?

A little. The 21 July sign-in incident fits the pattern: it was first posted 19 minutes after its first period’s stated start (11:18 a.m. PDT) and resolved 20 minutes after its end. The 21 July image-generation incident does not: OpenAI first posted it at 10:36 UTC, 76 minutes before the 11:52 UTC at which its write-up says the “most significant impact” began. The write-up does not say when the first, smaller errors began, so that is not necessarily earlier than the start of any impact. Adding both back gives 17 incidents, with 16 first posted after the stated start and 1 before, and a median of 19 minutes. Dropping the 30 July row, whose window is shifted about 75 minutes later, gives a median of 19.5 for the other 14. None of this changes the overall reading, but the one early post shows that the pattern is not a rule.

Which one is right?

Neither source is a measurement of user impact. The write-up is OpenAI’s retrospective, written after an investigation, and it states times as approximate. The status page is a live communication channel, and its times show when staff posted or set the updates. A write-up might date the start from internal monitoring that users could not see, and a status page might hold an incident open after recovery to watch it, which is part of how the stages work. In these 15 incidents the first post was never earlier than the write-up’s start and “resolved” was never more than a minute earlier than its end. That direction is partly built in, because a page cannot post before OpenAI detects a problem and “resolved” follows monitoring, so it shows how the two accounts relate and does not show the page is wrong.

For a user, the practical reading is that an incident often starts a little before the page says, and that a page still marked “monitoring” may or may not mean problems are continuing. In our 29 September case, OpenAI’s write-up says some services had residual degradation inside the monitoring stage, which shows that stage is not always idle.

What this means in practice

• If something is failing and the page says nothing yet, believe your own errors. In all 15 incidents the first post came after the impact start OpenAI later gave, by a median of 20 minutes.
• Do not read the page’s duration as downtime. It can be shorter than the impact when the first post comes late, and longer when the incident stays open through monitoring. In this sample, displayed time was more than 10 minutes longer than stated impact for 7 incidents and more than 10 minutes shorter for 5.
• Use write-ups when you need an impact window. They state one, with caveats, and they are listed in the review of OpenAI’s write-ups.

What we could not verify

• We cannot say which account matches what users saw. We have no independent measurements, such as user reports or our own probes.
• The write-up times are approximate and retrospective. Several are rounded to the nearest few minutes, so a gap of a few minutes is within the noise. The status page’s start may also have been used as a source for the write-up’s window, in which case the two are not fully independent.
• We excluded 2 of the 17 incidents with write-ups, summarised above, and our 15 are not a random sample, since OpenAI picks which incidents get a write-up and they skew to the more serious ones. The 402 minutes for 23 July treats a write-up with an initial recovery followed by a second wave as one continuous window, so it may overstate continuous impact.
• We took the first post from each incident’s published time and the resolve from the first “resolved” update. OpenAI can display a start earlier than it posted, as it did for two of the 15, and we did not look for the same on the resolve side beyond checking that the 31 August Free and Go close matches its write-up.
• We converted Pacific time to UTC assuming daylight time throughout (the 19 August write-up says “PT”), which applies on every date here.
• We do not know why the 23 July incident stayed open after the write-up’s recovery time, or why the first post comes later in every case.

How we researched this, and the data

Between 6 and 8 October 2026 we read each of the 15 incidents’ write-ups and incident pages. We took the write-up’s stated start and end from its summary section and converted them to UTC. We took the first post from the incident’s published time and its resolve from the first update marked “resolved”, and noted where the displayed start differs from the published time. The extraction was done by a script (dataset_openai.py), and the per-incident times for all 111 incidents, including the posting time next to the displayed start, are in this CSV. The differences were calculated by script from those figures. The two incidents with a displayed start earlier than the post time were found by comparing the incident’s published time with its first update’s time on each incident page. Our earlier looks at the 3 September and 29 September incidents are in this check of the Azure explanation and this comparison of the 29 September write-up.

Frequently asked questions