SaaS Outage Report Q3 2026: 3,271 Incidents Across 176 Vendor Status Pages

Between 1 July and 30 September 2026, 176 SaaS and cloud vendors posted 3,271 incidents to their public status pages. About three in four were labelled minor by the vendor. The other 796 were major or critical, and half of those were resolved within 1 hour 29 minutes.

Outages are a working-hours event. 89.5% of incidents started on a weekday, Thursday produced the most serious ones, and the busiest three-hour window was 15:00 to 18:00 UTC, which is late morning on the US East Coast. Between midnight and 06:00 UTC, the whole cohort posted only 14% of the quarter's incidents.

The vendor with the most incidents is not the least reliable one. Twilio posted 505 incidents in the quarter and only two of them were major, because Twilio files a separate notice for each carrier delay. Only 29 of the 176 vendors ever showed a page-wide major outage at any point in the quarter.

This report is for engineering, SRE and procurement teams who depend on other companies' APIs and want a baseline: how often vendors break, for how long, and when. It is built from incidents the vendors published themselves, collected by PulsAPI as it read each status page every few minutes (about 616 snapshots per vendor per day in Q3).

Three rules shape the numbers, and they matter more than any single figure. First, the cohort is limited to vendors that publish the Statuspage incident format, because only there does 'major' mean the same thing from one vendor to the next. That covers Atlassian Statuspage itself and hosts like incident.io that publish a compatible feed. Second, every vendor in it was tracked for the entire quarter; vendors added to PulsAPI after mid-June are left out, since a late addition only sees part of its history. Third, where several catalog entries read the same page (Cloudflare and Cloudflare Workers, GitHub and GitHub Copilot, the Atlassian products), each vendor incident is counted once. That removed 448 duplicate rows. SendGrid is excluded entirely because its feed currently carries Twilio's incidents.

Scheduled maintenance and incidents marked 'none' for impact are not counted. Duration runs from the vendor's first post to its resolution post. The 180 incidents without a usable resolution time (still open, or resolved before they started, which some vendors' feeds do) are excluded from duration figures but counted everywhere else. The aggregate tables are available as a CSV download.

The median vendor in the cohort posted 8 incidents in the quarter, roughly one every eleven days, and 2 of them were serious. The spread is wide: the 90th percentile vendor posted 48, while 23 vendors posted nothing at all and 38 had no major or critical incident.

For incidents a vendor called major or critical, the median was 1 hour 29 minutes. That number hides a long tail. 37.9% were over within an hour, but 23.0% ran four hours or more and 4.7% were still open a full day later.

Minor incidents last longer on average (the median across all incidents is 2 hours 16 minutes), which looks backwards until you read them. Many minor posts are things like delayed delivery receipts to one mobile carrier, and they stay open until the carrier fixes its side. Short, sharp outages tend to get the higher labels.

The practical consequence is for alerting. If more than a third of serious incidents clear inside an hour, paging someone the moment a vendor posts will often wake them for something that resolves before they finish reading it. PulsAPI holds status-change emails for five minutes for this reason, so an incident that opens and closes inside that window never reaches your inbox.

Weekdays, by a factor of more than three. An average weekday in Q3 produced 44 incidents across the cohort; an average Saturday or Sunday produced 13. The most likely explanation is the boring one: most incidents follow a change, and most changes ship during working hours.

Thursday stands out for serious incidents, at 13.4 per Thursday against about 10 on the other weekdays. We would not read much into that from one quarter. GitHub showed the same Thursday peak across March to October, though, so it is worth watching in the next report.

The table divides each day's total by how many times that day occurred. Q3 2026 started on a Wednesday and had 92 days, so it contained fourteen Wednesdays and thirteen of every other day. Raw totals would overstate Wednesday by about 8%.

The busiest window was 15:00 to 18:00 UTC, with 19.7% of all incidents and 20.7% of the serious ones. In Q3 that was 11:00 to 14:00 in New York and 16:00 to 19:00 in London, the hours when both continents are at work and deploying.

Half of the quarter's incidents (50.8%) started in the nine hours from 12:00 to 21:00 UTC. The six hours after midnight UTC were the quietest at 14.2%. If your on-call rotation is thinnest in the European morning and the US afternoon, it is thinnest when your vendors are most likely to break.

The table below covers well-known vendors from the cohort. Sort it by the serious columns rather than the total, and read the total as a measure of how much a vendor tells you, not how often it fails. Cloudflare is not in the table: in our data its feed was split across three catalog entries for part of the quarter, so a per-vendor count would be wrong in either direction. Its Q3 activity is covered in the Cloudflare outage history. GitHub Copilot's incidents are included in GitHub's row, because both come from githubstatus.com.

'Serious hours' adds up the duration of every major and critical incident. It is the closest thing in this data to a measure of time spent visibly broken, but it overlaps: two incidents open at once both count.

Twilio's 505 incidents are the clearest case. 353 of them had titles about message delivery or carrier networks, such as SMS delays from Twilio to a single network in one country. Those are real problems for a team sending texts to that network and irrelevant to everyone else. A vendor that files them is being more useful than one that doesn't, and a raw incident count punishes it for that.

Claude shows the same effect at a different scale. Anthropic tends to post a separate incident for each affected model ('Elevated errors on Claude Opus'), which gives it more incidents than OpenAI even though OpenAI's single page covers ChatGPT, the API, Codex and Sora. Stripe posted five. That does not prove Stripe broke less than Claude by a factor of seventeen. It proves the two companies make different decisions about what deserves a public post.

Page-wide red is rare. Across 16,171 vendor-days, a status page showed an overall major outage on 46 of them, and 147 of the 176 vendors never did at all. Most incidents degrade one component while the page headline stays green or amber. That is the main reason to watch the components you depend on rather than a vendor's overall status: the overall status will usually tell you nothing.

For a fair comparison between quarters, we used only the 123 vendors tracked since before April. They posted 2,265 incidents in Q2 and 2,565 in Q3, an increase of 13.2%. Major and critical incidents rose from 510 to 567 (11.2%). Critical incidents alone were flat, 135 in Q2 and 136 in Q3.

One quarter-on-quarter change is not a trend, and part of the rise is likely vendors posting more, not breaking more. The flat critical count is the more reassuring number, since it is the label vendors are least likely to use casually.

Staff for the hours vendors fail, not the hours you fail. The 12:00 to 21:00 UTC band carries half of all vendor incidents. If you run follow-the-sun on-call, that is the handover window where third-party outages most often land on whoever just came on shift.

Alert on components and severity, not on vendors. With a median of eight incidents per vendor per quarter, a team that depends on twenty vendors and alerts on every post will see about 160 notifications a quarter, most of them about components it does not use. Subscribe to the components on your critical path and route major and critical incidents to a page, minor ones to a channel. The incident severity guide covers how to map vendor labels to your own levels.

Ask vendors about their disclosure habits during procurement. A vendor with a short incident history is either very reliable or very quiet, and the status page alone cannot tell you which. Vendor status page accuracy and the status page transparency report go deeper on that question.

How often do SaaS vendors have outages? In Q3 2026 the median vendor in our cohort posted 8 incidents in 92 days, about one every eleven days. Two of those were labelled major or critical. The range is wide, from vendors with none to vendors posting several a week.

How long does a typical SaaS outage last? The median major or critical incident in Q3 2026 lasted 1 hour 29 minutes from the vendor's first post to resolution. 37.9% resolved within an hour, while 4.7% lasted a day or more.

What day do most outages happen? Weekdays. 89.5% of Q3 2026 incidents started Monday to Friday, and Thursday had the most major and critical incidents per day. Weekends averaged about 13 incidents a day across the cohort, against 44 on weekdays.

Which SaaS vendor has the most outages? By raw count in this cohort, Twilio, with 505 incidents in Q3 2026. Only two were major, though, because most were per-carrier delivery notices. Ranking vendors by incident count mostly ranks how much they disclose.

Can I cite or reuse this data? Yes. Please cite it as 'PulsAPI, SaaS Outage Report Q3 2026' with a link to this page. The aggregate tables are in the CSV, and live status for any vendor is on its PulsAPI status page.