On October 23, 2026, 27 Services Reported Incidents Together

Starting October 23, 2026, 27 services reported incidents within the same hour, well above the usual rate. The last affected service recovered 2 days 11 h after the first report.

The reports were closely timed; the recoveries stretched much longer. For engineers and IT teams reviewing affected dependencies, the individual incident records give a more specific timeline than the shared reporting hour alone.

Sage reported first; Twilio recovered last

Sage’s status and outage history contains the first report in the group: “Sage Business Cloud Accounting (UKI/NA) - Partial Outage.” For teams reviewing Sage’s involvement, that is the incident entry to match against their own timeline.

Twilio was the last service to recover. Its incident was titled “Voice Call Post Dial Delay from Twilio Phone Numbers to Chile,” and its resolution ended the cluster’s recovery window. Teams reviewing that dependency should match the named calling function to their own use of Twilio.

The Twilio status and outage history includes the longest reported incidents in this group as well as the last recovery. That makes its individual incident records particularly relevant to teams tracing how long their affected Twilio dependencies remained unresolved.

Communication had the most affected services

Communication was the largest affected category, with 6 services reporting incidents. Sage, Kaseya, Twilio, GitHub, Kraken, and Cloudflare were among the affected services, giving teams several named dependencies to check against their own incident timelines.

The category breakdown was Communication at 6, Developer tools at 5, Cloud & hosting at 4, and Productivity at 3. Developer tools followed Communication, ahead of Cloud & hosting and Productivity.

These category counts are small, so the ranking is a limited basis for broader category comparisons. Shared timing strongly suggests a common cause, but companies rarely name it; we do not guess.

See the full list of affected services to check which of your dependencies reported an incident during the shared hour. The service list below brings those reports together.

Service	Incident	Impact
Sage	Sage Business Cloud Accounting (UKI/NA) - Partial Outage	minor
Kaseya	Datto RMM v15.2.0 - Pinotage (EU1) - Device Filter Issue	critical
Twilio	Voice Call Post Dial Delay from Twilio Phone Numbers to Chile	minor
GitHub	Disruption with Dependabot Alerts	minor
Kraken	Solana (SOL) Network Funding Delays	minor
Cloudflare	Delayed, missed, and duplicated Workers Cron Triggers	minor
Bolt.new	Features → Prompting Degraded	minor
balena.io	Elevated API Errors	minor
Pitney Bowes	Intermittent Service Disruption observed for SendPro Enterprise for US region.	major
Blackbaud	Blackbaud Grantmaking	minor
Gladly	Intermittent Issues with Login and Routing	minor
ReadMe	Elevated 503 Errors and Documentation Availability	major
Dutchie	Dutchie POS Back Office and Register Errors	minor
Cloudflare	Network connectivity issues affecting services in North America	major
Navan	Inventory provider degradation	minor
Radar	Elevated API Latencies	minor
JumpCloud	Increased error rates loading User and Admin portal	major
Sinch	Delivery Issue Nicaragua - Tigo	minor
WorkOS	Elevated errors across SSO and AuthKit	major
Berklee IT Services	Outage: Microsoft Office	minor
Render	Degraded network performance	minor
Telnyx	10DLC phone number registration experiencing delays	minor
Ashby	Sporadic reports of Ashby unavailable	minor
Toast System	Toastweb - Toast App Performance Degradation	minor
Infobip	Global (Europe)- Conversations Slowness and Errors	minor

6 incidents were rated major or critical

Across the event, 6 of the 30 incidents were rated major or critical. The rest were minor.

The severity count covers incidents, while 27 is the count of services that reported within the hour. The event therefore included more incident entries than affected services, with both major or critical and minor ratings represented.

Twilio’s longest incidents extended beyond the median

The longest reported incident lasted 2 days 11 h at Twilio. Another Twilio incident lasted 19 h 16 min, followed by Berklee IT Services at 11 h 18 min; the median incident in the group lasted 3 h 20 min.

The longest Twilio and Berklee IT Services entries were above that median. For teams using Berklee IT Services, its own reported duration is the recovery interval to review rather than Twilio’s later resolution.

Twilio’s separate durations also matter. The archive contains distinct Twilio incident entries with different lengths, so teams should review the entry matching their affected function rather than assign the longest duration to every Twilio issue in the cluster.

What to check in your incident review

• Match dependencies to the reporting hour. Use the affected-services list to check your dependencies against the 27 services that reported incidents within that hour.
• Match the final Twilio report to your calling use. The last recovery concerned “Voice Call Post Dial Delay from Twilio Phone Numbers to Chile.”
• Check the duration of the matching incident. Twilio had entries lasting 2 days 11 h and 19 h 16 min, while Berklee IT Services had an entry lasting 11 h 18 min—different recovery intervals within the same cluster.

How we measured this

Incidents are those each company published on its own public status page, which we check every 5 minutes and archive permanently.

An hour counts as a multi-service outage when far more services than usual report a new incident in it: the normal hourly rate plus four standard deviations.

Limitations.

• Shared timing strongly suggests a common cause, but companies rarely name it; we do not guess.

Data: OutageDB archive of official status pages, as of 2026-10-26. Full details in our methodology.