Resolved — 31 August 2026, 22:16 BST. OpenAI marked the incident resolved at 21:28 BST and said all impacted services had fully recovered. The public incident record does not yet give a cause. The monitoring update and original developing-story account are preserved below.
Update — 31 August 2026, 21:16 BST. OpenAI says it applied a mitigation at 21:01 BST and is monitoring recovery. The incident remains classified as a partial outage and has not yet been marked resolved. The original developing-story account is preserved below.
Developing story. Last checked 31 August 2026 at 19:16 BST. OpenAI is reporting an ongoing partial outage affecting ChatGPT Work. This article will be updated if the company materially changes the incident status, scope or explanation.
OpenAI says some users across multiple subscription plans are unable to start or continue tasks in ChatGPT Work because of elevated errors and latency. The company’s official incident record remained open more than three hours after the first notice on 31 August, with a mitigation still being implemented.
The disruption matters because Work is not simply another conversational interface. It can run longer, tool-using tasks whose value lies in the work performed over time. When that service becomes unavailable, the operational question is not only whether a user can send a message. It is whether organisations know what completed, what remains unfinished and how to resume safely without duplicating consequential actions.
OpenAI has not disclosed a cause, the number or geographic distribution of affected users, or an estimated recovery time. There is therefore no basis at present for attributing the outage to a security incident, a model problem or a particular infrastructure failure.
What is established
OpenAI first reported elevated latency at 15:04 UTC. Seventeen minutes later, it said elevated errors were affecting the service and that Plus users were particularly affected, with Work mode unavailable. Later updates broadened the wording: users across multiple subscription plans may be unable to start or continue tasks in ChatGPT Work.
At 17:52 UTC, the company repeated that it was continuing to implement a mitigation. Its public status page classified the event as an identified partial outage affecting one ChatGPT component. The wider ChatGPT service was not described as completely unavailable.
BleepingComputer independently reported that affected users were encountering failures when starting new work or continuing existing tasks. That reporting is consistent with OpenAI’s status notices. User posts can help show how an incident is experienced, but they are not a reliable measure of total reach and are not used here to estimate the number affected.
The established facts are consequently narrow but significant: the provider has confirmed an ongoing service degradation; it spans more than one subscription tier; and the failure can interrupt active work, not merely delay access to a peripheral feature.
The operational and governance consequence
Agentic work creates a continuity problem that ordinary chatbot downtime does not. A long-running task may already have searched sources, edited files, called external tools or prepared material before the user sees an error. If the interface does not provide a dependable completion record, restarting can repeat an action or leave a partially changed system in an uncertain state.
Organisations should treat that uncertainty like any other interrupted operational process. The safe default is to reconcile before retrying. Check the target system, file history, audit record or transaction log to establish what actually happened. Do not infer completion from an optimistic status message, and do not infer failure merely because the visible task stopped.
This is closely related to the control problem discussed in AI Agent Control Failures Expose a Gap in Incident Reporting. The common requirement is durable evidence outside the model’s own narrative: what instruction was given, which tools were available, what actions were attempted, what changed and who authorised the next step.
For consequential workflows, a provider status page is useful but insufficient. A continuity design should include:
- task identifiers that can be matched to external actions and records;
- idempotent operations, so a retry does not create a duplicate payment, message, ticket or publication;
- checkpoints showing the last verified stage rather than only a final success or failure label;
- a human-readable activity record retained outside the affected AI service;
- a manual fallback for work whose delay would affect safety, rights, customers or public services;
- a recovery rule that requires reconciliation before an interrupted task is restarted.
Those controls are not an argument against using agentic systems. They are the ordinary reliability disciplines required when an AI tool moves from producing advice to changing operational state. As our earlier analysis Human Oversight Is a Workflow explains, meaningful oversight depends on evidence, authority and a route for intervention. An outage tests whether that route still works when the AI service itself is unavailable.
What remains unresolved
OpenAI has not said whether interrupted tasks will resume automatically, whether partial outputs remain available, or whether any failed attempts consumed usage allowances. It has also not published incident-specific guidance for organisations that connected Work to external systems. These are practical questions for affected users, but they should not be answered by assumption.
The incident record also does not establish that completed actions were lost, repeated or corrupted. Those are foreseeable risks during interrupted automation, not reported outcomes of this outage. The distinction matters: continuity controls should address credible failure modes without turning them into unsupported claims about what happened today.
Nor does a three-hour partial outage, by itself, establish a systemic reliability trend. That would require comparable incident data, affected-user measures and service-level evidence over time. Today’s event is important because it is live and interrupts a consequential mode of work, not because it proves a broader conclusion about OpenAI’s infrastructure.
What affected teams should do now
Teams using ChatGPT Work should pause repeated retries on tasks that can write, publish, send, purchase or modify external systems. First inspect those systems for partial completion. Preserve task identifiers, timestamps, error messages and any visible activity history. If work is time-critical, move to an approved fallback process and record why the substitution was made.
For low-consequence research or drafting, waiting for OpenAI to move the incident to monitoring or resolved status may be sufficient. For operational use, recovery should include a brief reconciliation: confirm the last completed step, compare expected and actual changes, and restart only the unfinished portion.
The next authoritative evidence will be OpenAI’s status updates: whether mitigation restores service, whether the affected scope changes and whether the company publishes a cause or post-incident account. Until then, the responsible conclusion is limited. ChatGPT Work is experiencing a confirmed partial outage, and some users cannot reliably start or continue tasks. The immediate governance lesson is equally concrete: work entrusted to an AI service needs recoverable state beyond the service itself.