Netlify-hosted sites returned errors for 26 minutes on 24 September 2026. Netlify's own status page confirms the fault sat on their edge network, not in anything you built or deployed.
Started
19:01 UTC
Duration
Lasted 26m
Source
IsDown
Next time
Netlify is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: High-Performance Edge Network, Standard Edge Network, Edge Functions
What happened?
Netlify opened an incident at 19:01 UTC titled "Error accessing Netlify-hosted sites", after reports of errors reaching sites hosted on the platform. Three components appear on the affected list: High-Performance Edge Network, Standard Edge Network, and Edge Functions. That spread points to the edge layer generally rather than one isolated tier, since both edge network tiers and the functions running on them were listed together. At 19:10 UTC, nine minutes in, Netlify posted that they were seeing signs of recovery and that service had returned to normal operation. The incident was marked resolved at 19:25 UTC, with Netlify stating they were no longer seeing elevated error rates. That gives a total of 26 minutes from first report to resolution. No root cause appears anywhere in the three updates Netlify published. They describe symptoms and recovery, not a mechanism, so why the edge network produced errors for those minutes is not on the record. No post-mortem has been published for this incident. No user reports were filed during the window, so there is no independent account of what sites or regions were hit hardest. Over the past 90 days Netlify has logged 10 incidents with a median duration of 29 minutes, which puts this one slightly below typical. Across all time Netlify has recorded 439 incidents, averaging 5.7 per month.
Learning
UptimeRobot's own probes, which check Netlify's API from EU and North America on a 60 second interval, stayed at 100% uptime across the 24 hour, 7 day and 30 day windows, and this incident is not registered against those probe checks. That is not a contradiction. The probes watch the API endpoint, while the incident sat in the edge network and Edge Functions layer that serves rendered sites to visitors, a different path entirely. A synthetic check hitting a stable API endpoint can pass cleanly while real visitors loading your site through the edge network get errors, because the two routes don't share the same failure points. This is the general shape worth remembering: your own uptime checks against your API or backend tell you your half is fine, but they say nothing about the delivery layer sitting between a visitor and your content. If your product serves pages through Netlify's edge, an API-only check would have missed this entirely. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
