Summary
- Zoom opened incident my4rs36dn5tf at 12:09:51 UTC with minor impact in its US region.
- The first notice covered failure to list Zoom Whiteboards; inability to create Zoom Tasks was added at 12:24:12.
- Zoom said it had identified the root cause at 12:33:25 but did not disclose it.
- The first phase entered monitoring at 12:45:35, so monitoring—not resolution—was the state at the 14:06:29 reporting cutoff.
- After the cutoff, both components were marked degraded again at 14:28:05 and returned to monitoring at 14:49:23.
- Zoom marked the incident resolved at 15:08:45 without a user count, error rate, technical explanation or data-integrity statement.
Recovery was not the end of the sequence
The first phase lasted 35 minutes and 44 seconds from the recorded start to monitoring. Zoom said the inability to list Whiteboards and create Tasks had been resolved, while continuing to watch the services.
That wording was accurate for the state then visible. It did not become a final resolution: two hours and 18 minutes after the incident began, Zoom posted another “identified” update and returned both components to degraded performance.
An incident timeline should therefore preserve two service phases rather than compressing the record into either one continuous outage or one clean recovery.
Whiteboard discovery failed before Task creation
At 12:09:52 UTC, Zoom identified one bounded action: users in the US region could not list Zoom Whiteboards. The company did not say that existing boards were deleted, inaccessible by every route or failing to save.
At 12:24:12, Zoom added an inability to create Zoom Tasks. That expansion links two collaboration workflows, but it does not establish failure of Zoom Meetings audio, video or every Whiteboard operation.
The distinction matters for response. A team may continue a live meeting while losing the shared artefact or follow-up task that turns discussion into accountable work.
The cutoff captured a monitored service, not a closed case
This briefing’s discovery window ended at 14:06:29 UTC. At that instant, the first recovery had been in monitoring for about 81 minutes, both components were shown as operational and the incident had no resolution timestamp.
The second degradation was published 21 minutes and 36 seconds later. It belongs in the completed chronology, but cannot be back-projected into the cutoff state.
This separation lets readers distinguish what an operator could know during the window from what the supplier later disclosed.
A recurrence changes the operational question
One recovery followed by a second degradation raises questions about whether the first mitigation was incomplete, whether a rollback occurred or whether a separate fault reached the same components. Zoom’s record answers none of them.
It says the root cause was identified twice, using nearly identical text, but does not name the dependency, change or failure mode. The status page also does not call the second phase a recurrence.
The evidence supports the chronology, not a causal theory.
Workflow impact is narrower than a meeting outage
Whiteboards and Tasks sit around the meeting itself: they hold shared context, decisions and assigned work. A listing failure can obstruct discovery of existing boards; a creation failure can stop a new task from entering the system.
For teams using these tools as their operating record, the consequence is delayed coordination and a risk of work being captured elsewhere without later reconciliation. For customers not using the affected functions, the impact may be negligible.
Zoom published no affected-user count, request-failure rate or tenant segmentation, so aggregate business impact cannot be calculated.
Resolution did not establish data integrity
At 14:49:23 UTC, Zoom again said the affected functions had been restored and moved to monitoring. The incident was marked resolved at 15:08:45, two hours, 58 minutes and 54 seconds after it began.
That elapsed record is not evidence of continuous degradation, because both components were marked operational between the two phases. Nor does “resolved” prove that every attempted Task was replayed or every Whiteboard list response was complete.
The company did not report data loss or corruption; equally, it gave no explicit integrity or backlog statement.
Continuity depends on reconciling missed work
Teams can reduce exposure by keeping meeting decisions in an exportable record, assigning an owner to reconcile Tasks created through temporary channels and recording board identifiers outside a single listing view.
After recovery, the useful check is not merely whether the interface loads. Operators should verify that Tasks attempted during both phases exist once, that ownership and deadlines survived, and that Whiteboards expected in each workspace are visible.
The next evidence to watch is a technical post-incident explanation, measured failure rates and an explicit statement on queued or failed writes. Until then, the bounded conclusion is that Zoom restored two collaboration services twice and closed the incident without explaining why the first recovery did not hold.