--- title: "October 2026 in data: the longest outage was on the calendar" description: "46 services, 179 lost minutes. Most belong to one Linode outage announced a month in advance, which still ran past both ends of its window." url: https://uptimeproject.org/blog/october-2026-in-data/ built: 2026-11-06T12:58:15.145Z --- [Back to blog](https://uptimeproject.org/blog) # October 2026 in data: the longest outage was on the calendar 3 November 2026 UptimeProject data reliability incidents October’s figures, from the same five probes and the same rules as everything else on the site ([methodology](https://uptimeproject.org/methodology/)). This covers the 46 services measured for the whole month. Ten more joined the registry on 23 October and wait for a full month before they appear in a roundup. ## The month in numbers - **35 of 46 services lost no minutes at all.** - 179 minutes were lost in total, across 11 services. - One service, Linode, accounts for 107 of them. - Our own coverage gaps, minutes where fewer than three probes could vote, came to at most 2 per service. ![Bar chart of minutes lost per service in October 2026. Linode 107, GitLab 18, GitHub 17, Quad9 10, GCP Compute Engine us-central1 7, Azure Blob Storage eastus 7, GCP Compute Engine europe-west1 6, Azure Blob Storage westeurope 3, Postmark 2, OVHcloud 1, Backblaze B2 1. Linode's and Quad9's bars are almost entirely down minutes; GitHub's is almost entirely degraded.](https://uptimeproject.org/blog/october-2026-in-data/lost-minutes.svg) ## Linode: announced, then overrun On 29 September Linode posted a [scheduled maintenance](https://stspg.io/l8pk8bdqb3vf) for 28 October, 04:00 to 05:30 UTC. The notice said Cloud Manager, the API and the CLI would be offline, and that running Linodes would not be affected. Our Linode check calls `api.linode.com/v4/regions`, so it measures exactly the part that was announced to go offline. What the probes saw: - First failed minute at 03:55 UTC, five minutes before the window opened. - Back up at 05:44 UTC, 14 minutes after the window closed. Linode marked the maintenance complete at 05:30. - 106 bad minutes inside a 109-minute incident: 99 down, 7 degraded. It was not the first time. Linode’s 66-minute outage on 19 August, from 04:23 to 05:29 UTC, sat inside an announced window for the same systems, also 04:00 to 05:30. That one finished on time. Our figures do not exclude announced maintenance. A request to the API at 04:30 failed whether or not it was on a calendar, and the leaderboard reports whether services answered. The notice still mattered: anyone who read it could plan around 90 minutes. Nobody could plan around the 19 that fell outside it. It is also the control-plane case from [What 99.99% uptime actually buys you](https://uptimeproject.org/blog/what-99-99-uptime-actually-buys-you/). The API was down for nearly two hours while, by Linode’s account, every running server stayed up. Linode’s figure on our leaderboard describes its API, not its servers. ## GitHub: one match, one miss On 1 October our probes opened GitHub incidents at 13:04 and 13:23 UTC. GitHub’s own [incident summary](https://stspg.io/cz0ngh11q0tf) describes “two periods of slow page loads and intermittent request failures” between 13:04 and 13:34 UTC. The start time matches to the minute. GitHub’s first status post went up at 13:37, after both periods had ended. On 7 October it went the other way. GitHub had two [write outages](https://stspg.io/96smrcth8bpg), 15:06 to 15:16 and 16:52 to 17:01 UTC, in which “actions that save or change data failed” across git, pull requests, issues, Actions and the API. Our probes recorded one degraded minute that day. Both of our GitHub checks are reads: a static file from the web front door, and the first step of an anonymous `git fetch` from a public repository. Reads kept working, so the probes had nothing to see. This is the limit [The endpoint you monitor decides the outage you can detect](https://uptimeproject.org/blog/the-endpoint-you-monitor-decides-the-outage-you-can-detect/) is about. Measuring writes needs an authenticated check, which we do not run today. ## The rest - **GitLab** lost 18 minutes in two incidents: 11 minutes from 07:02 UTC on 13 October, and 7 minutes from 16:02 UTC on 16 October. - **Quad9** lost 10 minutes in a single outage from 02:17 UTC on 14 October. All ten were down minutes: the resolver failed from every probe at once. - **GCP Compute Engine** had three incidents of 2 to 3 minutes in one week, across both measured regions: us-central1 on 15 and 21 October, europe-west1 on 17 October. - **Postmark** lost 2 minutes on 15 October. ## Minutes that never became incidents Azure Blob Storage lost 10 minutes in October, 7 in eastus and 3 in westeurope, spread over seven different days. None of them appears on the [incidents page](https://uptimeproject.org/incidents/). An incident is a run of at least two bad minutes, with gaps of up to two minutes bridged, and Azure’s bad minutes never came close enough together to form one. OVHcloud and Backblaze B2 each lost a single isolated minute. Those minutes still count against availability. They just never produce an entry in the incident list or its feed. ## The data - Every figure above comes from the [public API](https://uptimeproject.org/docs/api/): daily buckets from `/v1/services/{id}/uptime?period=90d`, incidents from `/v1/incidents`. - The [incidents page](https://uptimeproject.org/incidents/) and its Atom feed list every incident as it happens. - All measurements are published under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). New posts and methodology changes go out by [newsletter](https://uptimeproject.org/subscribe/) and [RSS](https://uptimeproject.org/rss.xml). If a figure here looks wrong, open an issue on [GitHub](https://github.com/UpPrj/uptimeproject/issues) or write to hello \[at\] uptimeproject \[dot\] org. New posts and methodology changes, by email. [Subscribe](https://uptimeproject.org/subscribe/)