Blog

When identified at 16:57 had already cleared Codex Web

2026-11-06

On 5 November 2026 the identified update on OpenAI incident 01M6P50GPP1V98EF8MJ9SH393R, at 16:57:41 UTC, still said elevated errors. The incident RSS listed Codex Web as Operational on that update. ChatGPT Work and dots stayed degraded until 17:05:56. The incident resolved at 04:31:37 UTC on 6 November.

At 16:57:41 UTC on 5 November 2026, the identified update on OpenAI incident 01M6P50GPP1V98EF8MJ9SH393R said users were seeing elevated errors and that a mitigation was still being implemented. The incident RSS for that same item lists Codex Web as Operational. ChatGPT Work and dots stay at Degraded performance. A restart of Codex Web, decided from the sentence, is on a component that update already marked operational. Work is not clear. Neither is dots.

What 15:25 named, and what joined at 16:26

The incident name is ChatGPT Work and Dots Errors. Impact on the public incidents feed is minor. created_at is 2026-11-05T15:25:03Z. resolved_at is 2026-11-06T04:31:37Z. That object has no components field. Each update in the feed has a body and no component list. The names are on the RSS, one list per item. The status page does not describe the component named dots, and it does not describe ChatGPT Work or Codex Web either. Copy the names as written. Codex API is a different component, and it is not on any item in this RSS.

• 15:25:03 UTC, investigating. "We're investigating a potential issue for the listed services and checking how it affects users. We'll share an update when we know more." Affected components: dots, Degraded performance, and ChatGPT Work, Degraded performance. Codex Web is not on this item.
• 15:30:00 UTC, investigating. The same sentence. The same two components, still degraded. Codex Web is still absent. From 15:25:03 to 16:26:31 is 1 hour 1 minute 28 seconds with no Codex Web row.
• 16:26:31 UTC, investigating. The same sentence again. Codex Web joins at Degraded performance. ChatGPT Work and dots stay at Degraded performance. This is the first item that names Codex Web. The title still does not.
• 16:57:41 UTC, identified. "We have identified that users are experiencing elevated errors for the impacted services. We are working on implementing a mitigation." Codex Web is Operational. ChatGPT Work and dots stay at Degraded performance. The sentence does not say which of the three moved.
• 17:05:56 UTC, monitoring. "We've applied a mitigation and are monitoring the affected services to confirm recovery." Codex Web, ChatGPT Work, and dots are all Operational. From the identified item to this one is 8 minutes 15 seconds. That is how long Work and dots stayed degraded after Codex Web was already Operational.
• 04:31:37 UTC on 6 November, resolved. "All affected services are operating normally again. We're sorry for the disruption, and we appreciate your patience." The three components are Operational, which is where the monitoring item had already put them. OpenAI has not posted a cause. Do not fill that gap.

The degraded windows are not the open incident. ChatGPT Work and dots run from 15:25:03 to 17:05:56, which is 1 hour 40 minutes 53 seconds. Codex Web runs from 16:26:31 to 16:57:41, which is 31 minutes 10 seconds. created_at to resolved_at is 13 hours 6 minutes 34 seconds. The monitoring item to the resolved item is 11 hours 25 minutes 41 seconds, and the components are Operational for that whole stretch. On the incident page fetched while writing this, the affected-components chart starts at 15:25:03.573Z and ends at 17:05:56.348Z. It does not run to resolved_at. The display clock on that page moves with the reader. The instants do not.

The night before was Conversations

Incident 01M6MBCX427A7113A3T4FJ1N6Y is a different ID. The name is Elevated error rates across paid ChatGPT plans. Impact minor. created_at is 2026-11-04T22:38:12Z. resolved_at is 2026-11-05T00:32:37Z, which is 14 hours 52 minutes 26 seconds before 01M6P50GPP1V98EF8MJ9SH393R was created. The RSS lists one component, Conversations. At 22:38:12 it is Degraded performance, and the body says some users on paid ChatGPT plans may see errors when sending messages. At 22:49:34, monitoring, Conversations is Operational. Resolved is 00:32:37. The component on that item is still Conversations, Operational. ChatGPT Work, dots, and Codex Web are not on this incident. The resolved body is the same apology sentence as the later ID. From that monitoring item to resolved is 1 hour 43 minutes 3 seconds. A note that stretches "ChatGPT errors" from 22:38 on 4 November through 04:31 on 6 November has merged two incidents and four component names into one outage. Conversations is not ChatGPT Work, not dots, and not Codex Web.

What the directories did with the same stamps

Host-Tracker prints the incident as 13 hours 7 minutes, from 15:25 to 04:31 UTC on the Work and Dots ID, impact minor, six updates. Subtracting the minutes they printed gives 13 hours 6 minutes. The feed's created_at and resolved_at differ by 13 hours 6 minutes 34 seconds. Their checkpoints, which test chatgpt.com from several locations, recorded no outage of 5 minutes or longer during this incident. That is a check of the marketing host. It is not a Work task, a dots run, or a Codex Web session.

Pulsetic prints 13 hours 6 minutes, from 3:25 PM on 5 November to 4:31 AM on 6 November, and the page does not name a time zone. Those hour and minute faces are the UTC stamps of created_at and resolved_at, with the 34 seconds dropped. The timeline minutes match the six RSS items. The card does not say Codex Web left at 16:57.

StatusGator files the same days as major, acknowledged at 3:26 PM UTC on 5 November, ended at 4:31 AM UTC on 6 November, and calls the length 13 hours and 5 minutes. That length is the gap from 15:26 to 04:31, one minute after created_at. The paragraph lists ChatGPT Work, ChatGPT, Dots, and Codex Web. The RSS has no component named ChatGPT. The group label on the incident page is ChatGPT, holding ChatGPT Work and dots, and the component name is dots, not Dots. StatusGator writes that a mitigation landed around 5:07 PM UTC and that ChatGPT Work and Dots returned first, with Codex Web still progressing while OpenAI monitored. The RSS has the opposite order. Codex Web is Operational on the identified item at 16:57:41 UTC, which is 4:57 PM. ChatGPT Work and dots become Operational on the monitoring item at 17:05:56 UTC, which is 5:05 PM. There is no item where Work and dots are Operational and Codex Web is still degraded. OpenAI's impact field is minor, not major. The resolved sentence says all affected services are operating normally again. It does not say a majority of users.

Technobezz records the six updates in Eastern time, from 10:25 a.m. investigating to 11:31 p.m. resolved on 5 November, which is 15:25 UTC through 04:31 UTC on 6 November. The "what is affected" line names ChatGPT Work and Dots. It does not name Codex Web. The 11:26 a.m. Eastern update is the item that added it.

Copy you can adapt

The weak version, which could be pasted onto the monitoring sentence or onto either resolved line:

OpenAI is mitigated as of 17:05 UTC. ChatGPT Work, dots, and Codex are back. The outage ran 13 hours, so count an afternoon and an overnight.

That paragraph costs the component that moved first, and it costs the clock. At 16:58 the identified item has Codex Web at Operational and ChatGPT Work and dots still at Degraded performance, so "Codex" is not a row on the page. Codex Web and Codex API are different components, and Codex API is not on this incident. At 17:10 all three named components are Operational and the status is still monitoring, so "back" is 11 hours 25 minutes ahead of resolved_at. The 13 hour figure is created_at to resolved_at. The degraded window for Work and dots ended at 17:05:56. Codex Web's ended at 16:57:41. A reader who forwards the weak paragraph tells the next person the product was down overnight, and that person never opens the RSS item that marked the components operational at 17:05.

A note that keeps the item and the list:

16:58 UTC, 5 November. OpenAI incident 01M6P50GPP1V98EF8MJ9SH393R, impact minor, created_at 15:25:03 UTC. The name is ChatGPT Work and Dots Errors. The identified update at 16:57:41 says users are experiencing elevated errors and that a mitigation is still being implemented. On the incident RSS that item lists Codex Web as Operational, and ChatGPT Work and dots as Degraded performance. Codex Web was not on the 15:25:03 or 15:30:00 items. It joined at 16:26:31, degraded, on an investigating item whose sentence is the same as the first one. Codex API is not on this incident. The incidents feed has no components field for this ID. OpenAI has not named a cause. Do not restart Codex Web from this sentence, and do not tell the team Work is clear.

17:10 UTC, 5 November. The monitoring item at 17:05:56 lists Codex Web, ChatGPT Work, and dots as Operational. The incident status is monitoring. resolved_at is not on the record yet. The night-before incident, 01M6MBCX427A7113A3T4FJ1N6Y, resolved at 00:32:37 UTC and its component was Conversations. It does not cover this ID. A customer who could not start a Work task at 16:40 is not answered by the 17:05 sentence, and a 13 hour duration is not the degraded window.

What not to do

• Do not treat the identified sentence as the component list. At 16:57:41 the body still says elevated errors, and Codex Web is already Operational.
• Do not mark ChatGPT Work or dots clear from the monitoring words alone without the list. The list is what moves them, at 17:05:56, eight minutes after Codex Web.
• Do not call Codex API from a row that says Codex Web. The RSS does not list Codex API.
• Do not read a 13 hour directory duration as the time the components were degraded. Work and dots were degraded for 1 hour 40 minutes 53 seconds. Codex Web was degraded for 31 minutes 10 seconds. The rest, through 04:31:37, is an open incident whose components are Operational.
• Do not merge 01M6MBCX427A7113A3T4FJ1N6Y into this ID. That component is Conversations, and it resolved at 00:32:37 UTC on 5 November.
• Do not promote StatusGator's recovery order. Work and dots did not return first.
• Do not invent a cause. Neither resolved line has one.

Operator checklist

1. Write the incident ID on the note. This afternoon is 01M6P50GPP1V98EF8MJ9SH393R. Last night was 01M6MBCX427A7113A3T4FJ1N6Y.
2. Read the RSS component list on that item, not only the sentence. The incidents.json object for this ID has no components field.
3. Keep the clock when a component joins and when it leaves. Codex Web joins at 16:26:31 and is Operational at 16:57:41. Work and dots wait until 17:05:56.
4. When a monitoring line lists every component Operational, keep the incident open until resolved_at. On this ID that is 04:31:37 UTC on 6 November.
5. Leave the cause blank until OpenAI writes it.

For the host we measure, /status/openai at 17:20 UTC on 6 November showed the service host reachable and the vendor column operational, with no probe incidents from 30 October 17:20 UTC to 6 November 17:20 UTC, and probe p50 about 145ms. At 17:22 UTC the same evening, OpenAI's status.json had indicator none and the description All Systems Operational. That top-level indicator is what the vendor column is reading. It is not Codex Web at 16:26, and the empty probe timeline does not replay ChatGPT Work. The probe is a GET of the public models list on api.openai.com. Reachable means that host answered. It does not open ChatGPT Work, run dots, or start Codex Web. The same two columns for other hosts are on /status. Copy the incident ID, the RSS list, and the item time. The 16:57 sentence is the moment Codex Web left, not the moment the incident closed.