Netlify logged a single incident on 29 September affecting sites served from its High-Performance Edge, posted and resolved at 08:46 UTC with a 0m duration on their status page. The fault was on Netlify's side, inside its edge network.
Started
08:46 UTC
Duration
Reported resolved
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.
What happened?
Netlify's status page shows one incident on this day, titled "Error accessing Netlify-hosted sites". It carries a single update, filed at 08:46 UTC, which both opens and resolves the incident in the same entry. The text says sites on the High-Performance Edge had returned to normal operation and that Netlify was no longer seeing elevated error rates. Because there is only one update, you cannot see how long the elevated error rates actually ran before Netlify noticed and filed this, so the 0m duration on record reflects the gap between the filing and the resolution, not necessarily the real span of impact. No components are listed as affected in the incident record, and there is no breakdown of which regions or site categories saw the elevated errors. No user reports were filed during the window. Over the past 90 days Netlify has logged 10 incidents with a median duration of 29 minutes, which gives you a sense of how this single-update, same-minute resolution compares with their more typical pattern. Across all time Netlify has recorded 439 incidents, averaging 5.7 per month. No post-mortem has been published, and Netlify's status page does not say what caused the elevated error rates on the High-Performance Edge.
Learning
UptimeRobot's own probes against Netlify's API, run from EU and NA regions at 60 second intervals, show 100% uptime over the past 24 hours, 7 days and 30 days, with this incident not registered against that check. That is not a contradiction. Netlify's incident describes elevated error rates on sites served from its High-Performance Edge, which is a content delivery layer separate from the API endpoint UptimeRobot was polling, so a clean API check and a real edge-serving problem can both be accurate readings of different parts of the same provider. This is the general shape of a lot of outages on platforms like Netlify: the control plane or API stays reachable while the layer that actually serves your visitors' pages has trouble. If your own monitoring only pings an API or a health endpoint, it will miss exactly this kind of edge-level fault, because it is watching a different system. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
