Sites served from Netlify's High-Performance Edge Network returned errors for 52 minutes on 5 October 2026. Netlify says the fault sat on its side, in the edge network that serves hosted sites, not in anything you control.
Started
12:44 UTC
Duration
Lasted 52m
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
What happened?
Netlify opened the incident at 12:44 UTC, reporting errors accessing sites on its High-Performance Edge Network. At 13:00 it said only that investigation was continuing, with no detail on scope or cause. At 13:17 Netlify said the issue had been identified and a fix was being implemented, still without naming what the issue was. By 13:24 a fix was in place and being monitored. The incident was marked resolved at 13:34, and Netlify's resolution note gives a different timeline to the update timestamps: it states the incident actually began at 12:19 UTC and service was restored at 13:14 UTC, roughly 25 minutes earlier on both ends than when the status page posted. The listed duration for the day is 52 minutes, and the single affected component named throughout is the High-Performance Edge Network. No user reports were filed during the window on this record. Netlify has not published a post-mortem, so the underlying cause of the edge network errors is not on the record beyond the word "identified". Over the past 90 days Netlify has logged 11 incidents with a median duration of 29 minutes, and across its full history it averages 5.7 incidents a month, so a single edge network disruption sits within its normal pattern rather than as an outlier.
Learning
UptimeRobot's own probes against Netlify's API, run from EU and NA regions at 60 second intervals, stayed at 100% uptime across 24 hours, 7 days and 30 days, and this incident was not registered against those checks. That is consistent with what happened: the fault was reported against the High-Performance Edge Network that serves hosted site content, not against the API surface those probes watch, so a clean API reading and a real outage for site visitors are both accurate at once. This is the shape to recognise in your own product: a provider can have one component broken for end users while every other component, including the one you happen to be polling, reports green the whole time. If your own uptime checks only hit an API or a status endpoint, they can miss a content-serving failure entirely, because that is a different system reporting through a different channel. Over the last 30 days UptimeRobot recorded 7 incidents on Netlify with a median duration of 36 minutes, all resolved, a slightly longer and more frequent pattern than Netlify's own 90 day figures show. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
