How can a static site deploy break the site?

The build succeeds but produces the wrong output: an environment variable missing in CI yields empty content, a CMS API hiccup during build bakes in blank pages, a framework upgrade changes routing and orphans half the URLs, or a base-path misconfiguration ships a site whose assets all 404. The platform happily serves the broken build with perfect 200s. Keyword assertions catch pages missing expected content, and a content-hash check alerts when a page changes at a moment no deploy was expected — together they turn 'deployed' into a verified claim.

What should I monitor on a static site besides the homepage?

The custom-domain TLS certificate (platforms auto-renew them — usually; the failure is silent when it isn't), one or two deep pages that exercise routing rather than just the CDN root, the third-party endpoints your site depends on (form handler, search API, comments service), and the scheduled rebuild pipeline if your content comes from a CMS — a heartbeat on that build job catches the site quietly going stale. The www-to-apex redirect is worth one monitor too; DNS changes break it more often than anything else.

Is uptime monitoring for a static site free?

Effectively yes. A static site's full monitoring footprint — homepage, a deep page, SSL certificate, a redirect check, and a couple of third-party endpoints — fits in 4-6 monitors, and CronAlert's free plan includes 25 monitors at a 3-minute interval with SSL monitoring, a status page, and email/Slack/Discord/webhook/push alerts. Keyword assertions, content-hash checks, and build-pipeline heartbeats start on the $5/mo Pro plan if you want the deploy-verification layer.

Uptime Monitoring for Static Sites (Netlify, GitHub Pages, Cloudflare Pages)

Q: Do static sites need uptime monitoring?

Yes — because the HTML being static doesn't make the delivery chain static. Your site still depends on DNS resolution, a TLS certificate that renews on schedule, a hosting platform (Netlify, GitHub Pages, Vercel, Cloudflare Pages) that has real outages, a build pipeline that can ship a broken or empty version, and usually third-party endpoints for forms, search, and comments. Every link in that chain fails independently of your 'unbreakable' HTML. The monitoring is also nearly free: a typical static site needs 3-6 monitors, well within CronAlert's free plan.

Q: How do I know if my Netlify or GitHub Pages site is down?

An external monitor checks your URL on a schedule from outside the platform and alerts you when it stops responding — platform status pages tell you about their infrastructure, not about your site specifically. A misconfigured custom domain, an expired certificate on your domain, or a bad deploy affects only you and never appears on netlifystatus.com. Point a free monitor at your homepage with a keyword assertion on real content, and you'll hear about your outage from your alerts rather than from a visitor.

"It's a static site — it can't go down" is one of those claims that's true about the files and false about the website. The HTML is immortal; everything that delivers it is not. Your visitors reach those files through DNS records someone can fat-finger, a TLS certificate that renews on a schedule until it doesn't, a hosting platform with its own incident history, and a build pipeline that can confidently publish a blank page. Static hosting eliminates the app server — the single most failure-prone component, granted — and leaves the entire rest of the chain intact.

The good news: a static site's monitoring footprint is tiny — a handful of checks covers everything, comfortably inside CronAlert's free plan. This guide walks the actual failure modes of Netlify, GitHub Pages, Cloudflare Pages, Vercel, and S3/CloudFront setups, and the checks that catch each one.

What actually takes static sites down

DNS. The apex ALIAS pointing at a retired load balancer, a CNAME dropped during a registrar migration, an expired domain (it happens to companies you've heard of), or a DNS provider outage. Nothing platform-side can save you from your own zone file.
TLS certificates on custom domains. Platforms provision and auto-renew certificates for custom domains — until a CAA record, a DNS change, or a verification hiccup quietly breaks renewal. The failure is identical to the certbot silent-renewal-failure pattern: nothing visible until expiry day.
Platform outages. Netlify, GitHub Pages, Vercel, and Cloudflare all have status pages because they all have incidents. Their status page tells you about their platform; only your monitor tells you whether your site is affected right now.
Broken deploys. The build exits 0 and ships the wrong thing: empty pages because a CMS API blipped mid-build, a missing environment variable rendering placeholder content, a base-path change 404ing every asset. The CDN serves the damage with flawless 200s.
The dynamic bits you forgot are dynamic. Form handlers (Netlify Forms, Formspree), search (Algolia), comments (giscus), analytics-gated content — third-party endpoints that fail independently while your pages stay perfect. Our third-party dependency guide covers the genre.
Redirect rules. www→apex, old-URL maps, trailing-slash handling — one bad _redirects edit and half your inbound links 404 while the homepage looks fine.

The core setup: four checks, all free

Homepage. The basic is-it-up check, every 3 minutes on the free plan.
One deep page. /blog/some-post/ or /docs/getting-started/ — a page that exercises routing and the full build output, not just the CDN's root object. Deploys that orphan URLs fail here first.
The SSL certificate. Included with the HTTP check — this is your early warning for the platform's certificate auto-renewal quietly breaking on your custom domain.
The www (or apex) redirect. A monitor on the variant your links use, expecting the redirect to land. DNS migrations break this constantly, and nobody notices for weeks because they always type the canonical form.

That's four monitors against a free-plan allowance of 25 — add one per critical third-party endpoint (the form handler POST target, the search API) and you're still in single digits, with email, Slack, Discord, webhook, and push alerts included.

The deploy-verification layer (Pro)

Status codes can't tell you the build shipped garbage — a blank page is a 200. Two Pro-tier checks close the gap:

Keyword assertions. Require a string that only a correct build produces — your site name in the footer, a product name in the hero, a version marker. An empty-template deploy or placeholder-content build fails the assertion the first check after it ships. See the keyword monitoring guide.
Content-hash checks. A SHA-256 content-change monitor on a page that should be stable alerts when it changes unexpectedly — catching both botched deploys and the defacement/DNS-hijack scenario where someone else's content appears at your URL. The inverse mode, content-stale, alerts when a page that should change (your blog index after each scheduled CMS rebuild) stops changing — the site quietly going stale is a real failure for content-driven static sites.

If your content rebuilds on a schedule — a CMS-backed site rebuilt nightly, or a GitHub Actions scheduled workflow regenerating pages — put a heartbeat on the build job too: the scheduled build silently stopping is the static-site equivalent of a dead cron.

Platform notes

Netlify / Vercel / Cloudflare Pages. Custom-domain certificates auto-renew; monitor the served certificate anyway — the renewal breaks rarely but silently (CAA records and stale DNS validation are the usual culprits). Forms and serverless functions are dynamic components; monitor their endpoints directly.
GitHub Pages. Remember the 60-day scheduled-workflow disable if your site rebuilds on a schedule in a quiet repo — the site stays up while its content freezes. HTTPS on custom domains depends on correct ALIAS/CNAME records; the redirect monitor earns its keep here.
S3 + CloudFront. No platform babysits you: certificate renewal (ACM handles it — if the DNS validation records survive), origin-access misconfigurations after bucket-policy edits, and invalidation mistakes are all on you. This stack benefits most from the deep-page check and keyword assertions, and our CDN and static asset guide covers the asset-level angle.

A status page, since you're already here

Static sites are often the public face of something — a product, a docs site, an agency's client work. CronAlert's free plan includes a hosted status page fed by the same monitors, which answers "is it just me?" for your visitors and looks considerably more professional than a Twitter reply. Setup is a checkbox per monitor; the status page guide has the details.

Frequently asked questions

Do static sites need uptime monitoring?

Yes — DNS, TLS, the hosting platform, the build pipeline, and third-party endpoints all fail independently of your HTML. The full setup is 4–6 monitors, inside the free plan.

How do I know if my Netlify or GitHub Pages site is down?

An external monitor on your URL — platform status pages report their infrastructure, not your misconfigured domain or expired certificate. Your outage usually isn't their incident.

How can a deploy break a static site?

By succeeding: empty pages from a mid-build CMS blip, missing env vars, base-path changes that 404 every asset — all served with perfect 200s. Keyword assertions and content-hash checks catch what status codes can't.

What should I monitor besides the homepage?

A deep page (routing), the SSL certificate, the www/apex redirect, your form/search endpoints, and — if content rebuilds on a schedule — a heartbeat on the build job.

Is monitoring a static site free?

The core setup is: CronAlert's free plan covers 25 monitors with SSL monitoring, a status page, and multi-channel alerts. The deploy-verification layer (keywords, content hashes, heartbeats) starts at $5/mo.

Five minutes, four monitors, zero dollars

Your static site earned its reputation for reliability — protect the parts that didn't. Homepage, deep page, certificate, redirect: create a free CronAlert account and all four are watching before your coffee cools, with keyword assertions and build heartbeats waiting on the $5/mo Pro tier when you want deploys verified too.