Blog

When resolved at 11:50 was not the last Actions incident

2026-11-04

On 4 November 2026 GitHub resolved incident smtdswd1h2w4 at 11:50 UTC. Actions moved again at 16:05 on xr3myzj7ms51 and at 17:40 on h02n9572mx9y. The 11:30 mitigation sentence left Actions degraded.

At 11:50 UTC on 4 November 2026 GitHub resolved incident smtdswd1h2w4. The resolved sentence closes that ID. It does not name the next two major IDs that moved Actions: xr3myzj7ms51 at 16:05 UTC, and h02n9572mx9y at 17:40 UTC. A workflow rerun decided from the 11:50 line is on the wrong incident by mid-afternoon.

What 09:49 named, and what joined later

smtdswd1h2w4 is impact major on GitHub's incident record. The clocks below are the update times on that page, in UTC. The component moves are on the incident JSON. GitHub's own component text says Git Operations is the performance of clones, pulls, pushes, and associated operations, and Actions is workflows, compute, and orchestration. A failed push and a workflow that did not start are different rows.

• 09:49 UTC: investigating. "We are investigating reports of degraded performance for Git Operations, Issues and Pull Requests." Those three move from operational to degraded performance. Actions is not on this update.
• 09:50 UTC: "Actions is experiencing degraded performance." Actions moves from operational to degraded performance. This is the first update that names it.
• 09:53 UTC: Pull Requests moves from degraded performance to partial outage. Git Operations, Issues, and Actions stay at degraded performance.
• 10:38 UTC: the body names elevated errors and intermittent failures for Pull Requests, Git Operations, and Issues. API Requests is still not on the component list.
• 11:11 UTC: "API Requests is experiencing degraded performance." API Requests moves from operational to degraded performance. This is the first update that names it.
• 11:17 UTC: "Some requests may fail or be delayed while we work to restore service." The five components stay where the 11:11 update left them. Pull Requests is still partial outage. The other four are still degraded performance.
• 11:30 UTC: "The degradation affecting API Requests, Git Operations, Issues and Pull Requests has been mitigated. We are monitoring to ensure stability." Those four move to operational. Actions stays at degraded performance. The update status on the JSON is still investigating.
• 11:43 UTC: monitoring. "The degradation affecting Actions has been mitigated." Actions moves from degraded performance to operational.
• 11:50 UTC: resolved. "This incident has been resolved." The same update says a detailed root cause analysis will be shared when it is available. The five components are already operational.

The page stamps run from 09:49 to 11:50. Technobezz recorded the same morning in Eastern time, from 4:49 a.m. investigating Git Operations, Issues, and Pull Requests, to Actions at 4:50 a.m., to resolved at 6:50 a.m. isinternetup.com's 4 November note, written around 09:53 UTC, had Pull Requests in partial outage and Git Operations, Issues, and Actions degraded, with API requests still operational. That matches the 09:53 update. API Requests joins at 11:11, so a summary that puts all five components on the 09:49 sentence has erased two clocks.

GitHub has not published the root cause. The resolved line says the analysis is still to come. Do not fill that gap with a guess.

The 11:30 sentence left Actions degraded

The 11:30 body lists four components and then says they are monitoring. A reader who stops at the sentence marks Actions clear. The JSON on that same update does not. Actions stays at degraded performance until 11:43, and the update that moves it is a different post, with status monitoring. Thirteen minutes of reruns sit in the gap. The words are not the component.

Two later IDs used the same Actions sentence

xr3myzj7ms51 opens at 16:05 UTC, 4 hours 15 minutes after the 11:50 resolved stamp. Impact major. The incident JSON is the component record. GitHub describes Pages as the frontend application and API servers for Pages builds, and Webhooks as real time HTTP callbacks of user-generated and system events.

• 16:05 UTC: investigating. Actions and Pages move from operational to degraded performance. Webhooks is not on this update.
• 16:12 UTC: Webhooks moves from operational to degraded performance.
• 16:17 UTC: Actions moves from degraded performance to partial outage. Pages and Webhooks stay at degraded performance.
• 16:34 UTC: "We have identified an issue with events that might trigger Actions. We have applied mitigations and are monitoring for recovery at this point. Customers may observe delayed status updates for their jobs." The update status stays investigating. Actions stays partial outage. Pages and Webhooks stay degraded performance. GitHub Status posted that sentence with the link to this incident ID.
• 16:45 UTC: the body says the Webhooks degradation has been mitigated and they are monitoring. The update status is still investigating. Webhooks moves to operational. Actions stays partial outage. Pages stays degraded performance.
• 16:48 UTC: monitoring. Actions and Pages move to operational.
• 16:49 UTC: "The degradation has been mitigated." The three components are already operational.
• 17:01 UTC: resolved, with the same note that a root cause analysis will follow.

The page stamps run from 16:05 to 17:01. The 17:01 sentence closes xr3myzj7ms51. Thirty-nine minutes later h02n9572mx9y opens, impact major, and the only component is Actions.

• 17:40 UTC: investigating. "We are investigating reports of degraded availability for Actions." Actions moves from operational to partial outage.
• 17:53 UTC: the body is the same events sentence as the 16:34 update on xr3myzj7ms51, including delayed status updates for jobs. The update status stays investigating. Actions stays partial outage. The incident JSON does not move the component.
• 18:07 UTC: monitoring. Actions moves from partial outage to operational.
• 18:16 UTC: resolved. The analysis is still to come. Actions is already operational.

The page stamps run from 17:40 to 18:16. GitHub has not said these three major IDs share a cause. Copy that treats 17:53 as an update to the 16:34 incident has merged two IDs the status page kept apart. The 16:48 update had already set Actions operational on xr3myzj7ms51. The 17:53 sentence is a new partial outage, not a late footnote on the one that resolved at 17:01.

Copilot Mission Control was a fourth ID

Incident tc28c0wzrnpz opened at 08:45 UTC, impact minor, and resolved at 10:01 UTC. The incident JSON has no affected components. At 08:47 the body said Copilot Mission Control was seeing increased error rates, about 2.5 percent, in listing and creating tasks, and named upstream database throttling as the line they were investigating. At 09:11 they wrote that a specific client version was identified and a mitigation was deploying. Monitoring is 10:01, and resolved is the same minute. That resolved line lands while smtdswd1h2w4 is still investigating, with Pull Requests in partial outage. It does not clear Actions, and it is not the Copilot component on the status page, because no component is on this incident.

Copy you can adapt

The weak version, which could be pasted onto any of the three resolved lines:

GitHub is resolved as of 11:50 UTC. Actions is back. If a workflow failed this morning, rerun it.

That paragraph costs the component that is still moving. At 11:32 the 11:30 update has API Requests, Git Operations, Issues, and Pull Requests at operational, and Actions still at degraded performance, so a rerun is the row the sentence left out. At 16:10 xr3myzj7ms51 is open, Actions and Pages are at degraded performance, and the 11:50 line is a different ID. At 17:45 h02n9572mx9y has Actions at partial outage, 39 minutes after xr3myzj7ms51 resolved, and the events sentence at 17:53 does not move that component. One note cannot be true for all three clocks. A reader who reruns from the weak paragraph also tells the next person the incident is over, so the 16:05 and 17:40 pages never get opened.

Three notes that keep the IDs apart:

11:32 UTC, 4 November. GitHub incident smtdswd1h2w4, impact major, open since 09:49 UTC. At 09:49 Git Operations, Issues, and Pull Requests moved to degraded performance. Actions was not on that update. Actions joined at 09:50. API Requests joined at 11:11. At 11:30 GitHub wrote that API Requests, Git Operations, Issues, and Pull Requests are mitigated. On the incident JSON those four are operational and Actions is still degraded performance. The update status is still investigating. Do not rerun workflows on this sentence. Actions moves on a later update. Pull Requests was partial outage from 09:53 until 11:30. GitHub describes Git Operations as clones, pulls, and pushes, and Actions as workflows, compute, and orchestration. A failed push and a workflow that did not start are different rows. The root cause is not on the page.

16:10 UTC, 4 November. smtdswd1h2w4 resolved at 11:50 UTC. That line does not cover the incident open now. xr3myzj7ms51 has been open since 16:05 UTC, impact major. Actions and Pages moved to degraded performance at 16:05. Webhooks was not on that update. Yesterday's resolved stamp is a different ID. GitHub has not said the two share a cause.

17:45 UTC, 4 November. xr3myzj7ms51 resolved at 17:01 UTC, after Actions and Pages returned to operational at 16:48. That line does not cover h02n9572mx9y, open since 17:40 UTC, impact major, Actions only, partial outage. The events sentence, if it is reposted, belongs to whichever incident ID is in the link. On xr3myzj7ms51 that sentence was 16:34 and did not move Actions off partial outage. A new ID with the same sentence is a new partial outage until its own component update says operational.

A reader who was not on the bridge can check each sentence against the incident JSON. The weak paragraph cannot be checked, so it cannot be trusted an hour later.

What not to do

• Do not mark Actions clear from a sentence that names other components. On smtdswd1h2w4 that sentence is 11:30, and Actions stays degraded until 11:43.
• Do not treat a body that says monitoring as the component move. At 11:30 and at 16:45 the update status is still investigating, and only some components change.
• Do not paste the 11:50, 17:01, or 18:16 resolved line onto a later incident ID.
• Do not merge the 16:34 and 17:53 events sentences into one incident. They are xr3myzj7ms51 and h02n9572mx9y.
• Do not attach tc28c0wzrnpz to Actions. It has no components, it is minor, and it resolved at 10:01 while Pull Requests was still in partial outage.
• Do not invent a root cause. Each resolved update says the analysis will be shared when it is available.

Operator checklist

1. Write the incident ID on the note. This morning is smtdswd1h2w4. The afternoon is xr3myzj7ms51, then h02n9572mx9y.
2. Read the component array on that update, not only the body. Actions can be absent, degraded, or partial while the sentence talks about a mitigation.
3. Keep the clock when a component joins. Actions at 09:50, API Requests at 11:11, Webhooks at 16:12.
4. When a resolved line lands, check whether a new ID has opened before you tell anyone to rerun.
5. Leave the root cause blank until GitHub publishes it. The events sentence is an update, not that analysis.

An earlier Actions and Pages incident, on 6 August 2026, is a different set of IDs, written up in partial outages and one green average. For the host we measure, /status/github at 18:35 UTC on 4 November showed the service host reachable, GitHub's own feed operational, and no probe incidents in the window from 28 October 18:35 UTC to 4 November 18:35 UTC, with probe p50 about 66ms. The two columns pointed the same way at that minute, which is after h02n9572mx9y resolved at 18:16. Reachable means the host answered. It does not run a workflow, build a Pages site, or deliver a webhook, and a green pair of columns at 18:35 does not replay Actions at partial outage at 17:40. The index of the same columns for other hosts is /status. The incident IDs and the component clocks still come from GitHub's status page. Copy those. The 11:50 line is the first of them, not the only one.