Live

Delayed Actions status check results

On October 23, 2026, between 07:06 UTC and 07:27 UTC, GitHub Actions workflow run results were delayed. Job status, check run updates, and logs in the GitHub UI and API updated with an average delay of about 2 minutes, and some updates were delayed by up to about 7 minutes. During this window, a storage dependency that Actions uses to process workflow logs and artifacts throttled our requests. This slowed result processing, causing updates to queue up. The queue was fully processed by 07:27 UTC, shortly after the throttling stopped. To reduce the risk of recurrence, we have added several storage accounts to increase capacity, and we are working on additional steps to continue to scale. We are also working with our storage provider to understand why the throttling occurred, and improving how result processing handles storage throttling and how quickly we detect it.

The latest update from GitHub.

State

Resolved

Started

9 d ago

2026-10-23 07:29 UTC

Lasted

36 min

until 2026-10-23 08:05 UTC

Worst impact

Degraded

Timeline

5 updates
07:2907:3807:4707:5608:05
DegradedUpdate postedTimes in UTC

Investigating

25 min 68%

Monitoring

12 min 32%

Updates

Times in UTC

As posted by GitHub

Resolved2026-10-23 08:05 UTC

On October 23, 2026, between 07:06 UTC and 07:27 UTC, GitHub Actions workflow run results were delayed. Job status, check run updates, and logs in the GitHub UI and API updated with an average delay of about 2 minutes, and some updates were delayed by up to about 7 minutes. During this window, a storage dependency that Actions uses to process workflow logs and artifacts throttled our requests. This slowed result processing, causing updates to queue up. The queue was fully processed by 07:27 UTC, shortly after the throttling stopped. To reduce the risk of recurrence, we have added several storage accounts to increase capacity, and we are working on additional steps to continue to scale. We are also working with our storage provider to understand why the throttling occurred, and improving how result processing handles storage throttling and how quickly we detect it.

Monitoring2026-10-23 07:56 UTC

As of 07:27 UTC, Actions results are delivering within normal SLOs again. Thank you for this patience during this period of delayed Actions results delivery. Our team continues to monitor system health and explore refinements to reduce impact to customers in the future.

Monitoring2026-10-23 07:53 UTC

The degradation affecting Actions has been mitigated. We are monitoring to ensure stability.

Investigating2026-10-23 07:31 UTC

We are seeing delays in results from Actions workflows being reported within GitHub starting from 07:07 UTC. Recovery is already being seen but our team is continuing to investigate and monitor performance.

Investigating2026-10-23 07:29 UTC

We are investigating reports of degraded performance for Actions

Affected components

1
Actions

GitHub in the last 90 days

Full history
90 days agoToday

Incidents in 90 days

46

Days with an incident

34

Median duration

1 h 29 min

This incident

59% shorter than the median

How long each incident lasted, on the day it started. The outlined bar is this incident.

20 h 7 min
median 1 h 29 min
90 days agoToday

Other GitHub incidents

All incidents

Follow GitHub

Your coding agent knows when GitHub is down, and tells you when a failure is theirs, not yours. You can also get GitHub incidents in a feed reader or in Slack.

Prompt
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.

Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.

Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "github" and tell me if GitHub has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.

Paste this into any coding agent. It adds the server with its own MCP setup.

RSS
https://outages.cc/feed.xml?providers=github
Slack
/feed subscribe https://outages.cc/feed.xml?providers=github

FAQ

Go from tracking outages to fixing production issues with Polylane.

Try Polylane