Netlify does not include uptime monitoring for your site. The platform will notify you about deploys and show you build logs, and its status page reports the health of Netlify's own infrastructure, but nothing at Netlify periodically visits your production URL and alerts you when the visit fails. If you want to know your site is up, you add an external monitor and point it at the things that actually break.
The good news is that a Netlify deployment has a short, well-defined list of things that actually break, and covering them takes one evening. This article walks the split between what Netlify tells you and what it cannot, then the five checks that cover a Netlify site properly, then the alerting and communication layer that turns detection into response, including the case where the outage is Netlify's and your job is telling your users while it lasts.
What Netlify tells you, and the gap
Netlify's built-in signals are build-side. Deploy notifications tell you a build succeeded or failed, the deploy log tells you why, and the platform's status page at netlifystatus.com reports incidents across its own components. All three are worth having and none of them answers the operational question. A deploy can succeed while the running site is broken, a missing environment variable, a runtime error the build never exercised, and the reverse is just as real: your site can be down for reasons no deploy caused, a DNS record changed at the registrar, a certificate renewal that failed quietly, a function dependency out of quota.
The structural gap is the same one every hosting platform has: the platform sees itself, and partially sees your site from the inside, while your users experience the whole chain from the outside, registrar to DNS to edge to certificate to content. Only a check that travels the same chain measures the same thing.
The five checks that cover a Netlify site
Check the production URL from multiple regions. The foundation: a request to your primary domain every minute or few, from several geographic locations, alerting on failure or slowdown. Netlify's edge network is distributed, which means problems can be regional; a monitor with a single vantage point averages exactly the failures a CDN makes possible.
Check the routes that constitute the product. The home page loading proves little if sign-in is broken. Add the login page, the checkout or key conversion path, and the API routes your product depends on, so a partial outage fails a specific named check instead of hiding behind a green home page.
Check your Netlify Functions endpoints separately. Functions fail on their own schedule, timeouts, quota exhaustion, a broken dependency, and a static site can look perfect while its dynamic half is down. Give each critical function an explicit check, and treat form handling the same way if your site depends on it.
Watch DNS and the domain itself. Netlify hosts the site; your registrar and DNS provider decide whether anyone can find it. Monitor that the domain resolves correctly and that the registration is not approaching expiry, because both failure modes are rare, total, and invisible from inside the platform.
Watch the SSL certificate on your custom domain. Netlify provisions and renews certificates automatically, and the automation is good, but renewals do fail, most often after DNS changes or when a new subdomain enters the picture, and an expired certificate is a full outage for every modern browser. A certificate check with an expiry warning window turns that scenario into a calm email weeks ahead; the mechanics of what goes wrong at this layer are covered in Odown's guide to SSL certificate errors.
Alerting, intervals, and the content check
Detection only counts if it reaches a human in time, so route alerts where your team already looks, Slack, email, a phone for the on-call hours, and set check intervals to match the cost of a missed minute: a commerce or SaaS front door justifies one-minute checks, a documentation site can breathe easier. Add a content or keyword check on the pages that matter, asserting that a phrase that should be on the page actually is, because the sneakiest Netlify failure is the deploy that ships successfully and renders an error screen with a confident 200 status; a status-code check waves that through, a content check fails it in one pass.
Then cover the platform-outage case honestly. When Netlify itself has an incident, your fix is patience, but your responsibility is communication, and a status page of your own, hosted independently of both your site and Netlify, lets you acknowledge the problem and post updates while it lasts. Odown's status pages run on separate infrastructure for exactly this reason, and subscribing your monitor's history to the page gives users the uptime record without you writing it.
Common mistakes in monitoring Netlify sites
Trusting the deploy notification as an uptime signal. It reports the build, not the site. The deployed-but-broken failure mode is common enough that content checks exist specifically for it.
Watching netlifystatus.com instead of your own domain. The status page covers Netlify's components; your DNS, domain, certificate, and application failures never appear there. Both are worth watching; only one is about you.
Monitoring the apex and forgetting the functions. Static uptime and dynamic uptime are different facts on Netlify. A function quota or timeout takes down the interactive half while every page keeps loading.
Checking from one location. Edge networks fail regionally. A single-vantage monitor in the wrong region reports perfection during an outage your customers in another one are living through.
Setting alerts nobody receives at night. A check that emails an unwatched inbox at 3 a.m. detected the outage and told no one. Route by severity and hour, and test the routing once a quarter.
FAQ
Does Netlify have built-in uptime monitoring?
No. It provides deploy notifications, build logs, and a status page for its own infrastructure, and none of those visits your production site on a schedule. External monitoring supplies that layer.
How do I know if it is Netlify that is down or my site?
Compare your own monitor's results with Netlify's status page. Your checks failing while Netlify reports healthy points at your DNS, certificate, or application; both reporting trouble means a platform incident, and your move is communicating through your status page.
How often should a Netlify site be checked?
Often enough that detection beats your users: every minute for revenue-bearing sites, a few minutes for lower-stakes ones, always from multiple regions so a regional edge problem cannot hide.
Do I need to monitor Netlify Functions separately?
Yes, if the product depends on them. Functions fail independently of static delivery, through timeouts, quotas, and dependencies, so each critical endpoint deserves its own check and alert.
Closing thought
Monitoring a Netlify site is a matter of covering the chain the platform does not: the domain and DNS you registered elsewhere, the certificate automation that occasionally misses, the functions that fail independently, and the deployed-but-broken page that only a content check catches. Five checks, multi-region, with alerts routed to where humans actually are, and the gap between Netlify's build-side signals and your users' experience closes completely.
Odown covers that whole list in one place: uptime and content checks from 17 locations, SSL and domain-expiry monitoring, function and API endpoint checks through its website monitoring, alerts in Slack, Discord, or wherever your team responds, and an independently hosted status page for the days the outage is upstream and your job is keeping users informed.
