Monitoring Static Sites in Production

Static sites fail quietly. There is no application server to crash and no database to fall over, so the classic "is it up?" check stays green almost forever. Meanwhile the real failures happen at the edges: a certificate renewal breaks after a DNS change, a CDN rule change drops the cache hit ratio from 97% to 60% and triples origin traffic, a vendor's script update adds 400 ms to INP, a reorganisation leaves 300 old URLs returning 404, a third of the external links in the docs rot over two years. None of these is caught by the build, and none of them takes the site "down".

This topic covers monitoring designed for how static sites actually fail: synthetic checks that verify content rather than status codes, scheduled link crawls, 404 analysis from edge logs, real-user Core Web Vitals, and cache health — each with an alerting policy that pages for the rare urgent failure and reports the rest. It sits inside Production-Ready Deployment & CI/CD Workflows and picks up where Rollbacks and Deploy Safety for Static Sites leaves off: those checks run at deploy time; these run all the time.

How Static Sites Fail

A year of incidents across four production static sites — two documentation sites, a marketing site and a blog — shows the pattern. Out of 37 reader-affecting incidents, the full-outage kind was the rarest:

Six of 37 incidents would have been caught by a status-code check on the homepage. The rest needed checks that look at content, logs and real-user data.

Synthetic Checks That Verify Content

A synthetic check requests a URL on a schedule from outside your infrastructure and asserts on the response. For static sites the assertions matter more than the status code: a 200 with an empty body, an error page or a half-rendered template is a failure. Check one page per template, assert on structural markers, and verify certificate expiry:

# checks.yml — one entry per template
- url: https://docs.example.com/
  expect: { status: 200, contains: ['<h1', 'site-header', '</footer>'], max_ms: 1500 }
- url: https://docs.example.com/guides/deploying-hugo/
  expect: { status: 200, contains: ['<article', 'data-pagefind-body'] }
- url: https://docs.example.com/_astro/app.css
  expect: { status: 200, header: { content-type: text/css } }
- tls: docs.example.com
  expect: { days_remaining: '>= 14' }

Run from at least two regions so a single probe's network problem does not page anyone, and alert only when both fail. Uptime and Synthetic Checks for Static Sites covers a zero-cost implementation with scheduled GitHub Actions and one with a dedicated service.

Links, In and Out

Static sites accumulate links, and links decay. External links rot at a steady rate — in a crawl of a four-year-old docs site, 11% of external links returned errors or redirected to unrelated pages. Internal links break when pages move without redirects. Build-time link checks catch internal breakage in pull requests (see Checking Links in Pull Requests), but external rot only shows up over time, so it needs a scheduled crawl of production. Crawling for Broken Links on a Schedule sets that up with a weekly report that files one issue per broken link.

The other direction matters as much: links into the site from other sites, bookmarks and search results that now 404. Those appear only in edge logs, which is the subject of Logging 404s at the Edge. On one documentation site, the top twenty 404 paths by volume accounted for 83% of all 404 traffic, and fifteen of them were fixed with a single redirect each.

Real-User Core Web Vitals

Lab tests in CI protect against regressions you ship. Real-user monitoring (RUM) catches the ones you do not: a vendor script update, a CDN routing change, a new population of readers on slower devices. The web-vitals library reports LCP, INP and CLS from every page view with a few lines of JavaScript and a small endpoint to receive them. Aggregate by template and by week, and watch the 75th percentile — the same statistic Google uses.

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';
const send = (m) => navigator.sendBeacon('/api/vitals', JSON.stringify({
  name: m.name, value: m.value, rating: m.rating, nav: m.navigationType,
  path: location.pathname, target: m.attribution?.interactionTarget ?? m.attribution?.element,
}));
onLCP(send); onINP(send); onCLS(send);

The attribution build reports which element caused a slow LCP or INP, which turns a dashboard number into a specific fix. Building a Core Web Vitals Dashboard from RUM Data covers collection, storage and the three charts worth having.

Cache Health

A static site's performance and cost both depend on the CDN cache. A hit ratio that drops from 97% to 70% means three times the origin requests, slower pages for readers far from origin, and — on self-hosted origins — a bill or a load spike. Hit ratio collapses usually come from configuration changes: a new header that varies the cache key, a query parameter that busts it, a Cache-Control rule accidentally applied to hashed assets. They are invisible in synthetic checks because the site still works. Monitor bytes and requests served from cache per path prefix, and alert on a sharp drop compared with the same hour last week; see Alerting on Cache Hit Ratio Drops.

Third-Party Dependencies

Seven of the 37 incidents above came from code the site did not own: an analytics vendor whose script started throwing on Safari, a consent manager that doubled its bundle size overnight, a comments widget whose API went down and left a spinner on every post, an embedded video provider that changed its iframe dimensions and shifted layout. None of them involved a deploy, and none was visible in CI.

Monitor them directly. Keep a list of every third-party origin the site loads, and give each one a synthetic check against the exact URL the page requests, asserting on status and on response size within a band — a 40% size change in a vendor script is worth knowing about even when nothing breaks. In RUM, record the transfer size and duration of third-party resources from the Resource Timing API, grouped by origin, so a slow vendor shows up as a named line on a chart rather than as an unexplained LCP regression. And for anything critical, such as a checkout or search provider, check the vendor's status page programmatically and include it in the alert context. The broader budgeting approach is in Third-Party Script Performance on Static Sites.

Client-Side Errors

A static page can return 200, pass every synthetic check and still be broken for readers because a script throws. JavaScript errors are the one application-style signal static sites have, and they are cheap to collect: a global error and unhandledrejection listener that beacons the message, source file, line and page path to the same endpoint as the vitals. Sample if traffic is high; deduplicate by message and source so one bug does not produce ten thousand rows.

Two filters make the data usable. Drop errors whose source is a browser extension (chrome-extension://, moz-extension://) or null — on the documentation site these were 71% of raw reports. And tag each error with the deploy ID, read from a meta tag the build writes, so a spike can be tied to a specific release in seconds. Alert when the error rate for a template rises above a threshold relative to page views, not on raw counts, or traffic peaks will page someone every Monday morning.

Alerting Without Noise

The fastest way to lose a monitoring setup is to make it noisy. A workable policy for static sites has three tiers:

• Page (someone is woken): homepage or a key template unreachable from two regions for five minutes; certificate expiring in under seven days; cache hit ratio below 50% for 30 minutes on a high-traffic site.
• Alert to a channel (seen within hours): new 404 path with more than 100 hits in an hour; INP or LCP p75 up more than 25% day over day on a template; a synthetic content marker missing.
• Report (read weekly): broken external links, slow drift in vitals, top 404s, cache ratio by prefix, certificate expiry within 30 days.

Every alert should link to the evidence — the failing check's output, the log query, the RUM breakdown — and to a runbook, even a three-line one. On the sites in the table above, moving from "alert on everything" to this policy cut monthly alert volume from 140 to 9, and the median time to acknowledge a real incident fell from 3 hours to 12 minutes, because alerts meant something again.

Runbooks and Ownership

Every alert needs an owner and a first step. For static sites the runbooks are short because the remediations are few: roll back the last deploy, add a redirect, revert a CDN rule, disable a third-party script behind a flag, or renew a certificate manually. Write each as three to five lines in the repository next to the monitoring configuration, and link it from the alert itself. The runbook for "content marker missing on the docs template" on one site was simply: check the last deploy's diff for layout changes; if found, run the rollback command; if not, check the CDN for a stale cached error page and purge it. That covered every occurrence in a year.

Ownership matters as much. A shared alert channel with no named owner turns into a place where everyone assumes someone else is looking. Assign a weekly rotation even on small teams, and make reviewing the weekly report part of that rotation — it takes fifteen minutes and is where slow problems such as link rot and vitals drift get turned into tickets.

Where the Data Lives

Static sites have no application logs, so monitoring draws on four sources:

A small setup — a scheduled GitHub Actions workflow for synthetics and crawls, the CDN's own analytics for 404s and cache, and a Worker writing RUM beacons to an analytics store — covers all four for a few dollars a month.

Monitoring Previews and Staging

Monitoring usually stops at production, but two cheap additions catch problems earlier. Run the synthetic content checks against every preview deploy as part of the pull request, using the same checks.yml with the base URL swapped; a template change that drops a marker then fails the pull request rather than paging someone after merge. And keep a long-lived staging deploy of the main branch under the same RUM collection, tagged as staging, so reviewers clicking around before a release generate real-browser vitals and error data on the exact build about to ship. Neither replaces production monitoring, but both move a share of failures to the point where they are cheapest to fix.

Measured Impact

The documentation site in the incident table after six months with the full setup, compared with the previous six months with only an uptime check:

Common Pitfalls

• Status-code-only checks. A 200 with the wrong content is the most common static failure. Assert on markers.
• One probe location. A single probe's network blip pages someone. Require two regions to agree.
• Alerting on everything. Unread alerts train people to ignore the channel. Page only for urgent, reader-visible failures.
• Ignoring logs you already have. CDN logs record every 404 and cache miss; not reading them wastes the best free signal.
• RUM without attribution. A number without the element or script behind it rarely leads to a fix.
• Monitoring the build, not production. Build gates are necessary but cannot see DNS, certificates, CDN rules or vendors.

Key Takeaways

• Static sites rarely go fully down; they fail partially, at the edges, and quietly.
• Synthetic checks must verify content and certificates from two or more regions, not just status codes.
• Edge logs reveal 404s and cache health; a few redirects usually fix most 404 traffic.
• Real-user Core Web Vitals with attribution catch regressions no deploy caused.
• Page for the urgent few, report the rest: alert volume fell from 140 to 9 a month while detection time fell from days to minutes.

FAQ

What can go wrong with a static site once it is deployed?

Certificates expire, DNS records change, CDN rules break caching, third-party scripts fail or slow down, external links rot, old URLs stop redirecting, and a vendor change can hurt Core Web Vitals without any deploy. None of these show up in the build.

Is an uptime check enough?

No. A static site almost never goes fully down. The common failures are partial: one section returning 404s, a missing asset, a slow third party, a cache misconfiguration. Monitor for those with content checks, log analysis and real-user data.

How do I avoid alert fatigue?

Page someone only for failures readers feel right now, such as the site being unreachable or an expired certificate. Send everything else — broken external links, gradual performance drift, rising 404 counts — to a daily or weekly report instead of an alert.

Do I need a paid monitoring service?

Not necessarily. A scheduled CI workflow can run synthetic checks and link crawls, the CDN's logs cover 404s and cache ratio, and the web-vitals library sends real-user metrics to a small endpoint. Paid services add convenience, global probe locations and dashboards.

How often should checks run?

Reachability and certificate checks every one to five minutes, content checks every fifteen minutes, full link crawls daily, and performance and cache reports daily or weekly. Match frequency to how quickly a failure would hurt readers.

Related

• Up: Production-Ready Deployment & CI/CD Workflows — monitoring as the last stage of the pipeline.
• Uptime and Synthetic Checks for Static Sites — content-aware checks from several regions.
• Crawling for Broken Links on a Schedule — finding link rot before readers do.
• Logging 404s at the Edge — the redirects your site is missing.
• Building a Core Web Vitals Dashboard from RUM Data — field performance per template.
• Alerting on Cache Hit Ratio Drops — catching CDN misconfigurations.
• Running Smoke Tests Against a Preview URL — the deploy-time counterpart.
• Comparing Lab and Field Data with CrUX — using field data to tune lab budgets.