# Observability for static sites: logs, errors, and real user metrics that actually help

Ben Morin, 2026-08-05. https://bemorin.com/writing/observability-static-sites-practical-guide

> A static site on a CDN is not “nothing to observe.” Users still hit broken assets, hydration mismatches, slow third parties, and edge rules that silently 404. This guide walks through a lean observability stack: what to capture, where to capture it, and what to ignore so alerts stay rare and actionable.

<h2>1) Reframe the goal: signals, not dashboards</h2>
<p>
  Observability is not about collecting everything. It is about answering three questions quickly: <strong>Is the site reachable?</strong>{' '}
  <strong>Are users seeing errors?</strong> <strong>Are we slower than last week?</strong> Everything else is optional until those three are
  boring.
</p>
<p>
  Static hosting makes uptime easy; most incidents are configuration, cache, or client-side. Plan instrumentation around those failure modes first.
</p>

<h2>2) Edge logs: your first line of defense</h2>
<p>
  Whether you use Cloudflare, Fastly, Netlify, Vercel, or S3+CloudFront, enable access logs or logpush to a cheap sink. You want at minimum:
  timestamp, host, path, status, bytes, cache status, referrer (sanitized), and edge PoP if available.
</p>
<ul>
  <li><strong>4xx spikes:</strong> often bad deploys, missing files, or aggressive ad blockers blocking analytics — triage by path prefix.</li>
  <li><strong>5xx at edge:</strong> origin timeouts, misconfigured workers, or certificate issues — correlate with deploy times.</li>
  <li><strong>Cache “BYPASS” on static assets:</strong> investigate cache keys and versioning; you may be shipping no-cache by accident.</li>
</ul>

<h2>3) Client-side errors: capture without drowning in noise</h2>
<p>
  Install a lightweight error SDK (Sentry, Highlight, or similar) with sampling. Register global handlers for <code>window.onerror</code> and{' '}
  <code>unhandledrejection</code>. Tag releases with your Git SHA so you can bisect regressions.
</p>
<p>
  Filter aggressively: ignore extensions, known third-party script failures, and bots. Group issues by stack fingerprint, not by raw message text.
</p>

<h2>4) Real user monitoring (RUM) without vanity metrics</h2>
<p>
  Core Web Vitals are useful when measured on real sessions — not just lab tests. Track LCP, INP, and CLS at the 75th percentile by page template,
  not by URL with infinite cardinality.
</p>
<ul>
  <li><strong>LCP:</strong> image priority, font loading, hero asset dimensions.</li>
  <li><strong>INP:</strong> long tasks, main-thread blocking scripts, excessive layout thrash in SPAs.</li>
  <li><strong>CLS:</strong> unsized media, late-injected banners, web fonts swapping metrics.</li>
</ul>

<h2>5) Synthetic checks for the boring stuff</h2>
<p>
  Run a 1-minute ping from two regions against <code>/</code> and one deep link (e.g. a blog article). Alert on non-200, TLS expiry, and sudden
  latency jumps. This catches DNS mistakes and certificate renewals before humans do.
</p>

<h2>6) Build and deploy visibility</h2>
<p>
  Static does not mean “no pipeline.” Store build logs, artifact sizes, and deploy duration. A sudden 3× bundle growth is an observability
  event — it predicts future performance pain.
</p>

<h2>7) Privacy and retention</h2>
<p>
  If you capture IPs or client identifiers, align retention with your privacy policy. Hash or drop IPs at ingest where possible, and avoid
  shipping PII in URLs or error messages.
</p>

<h2>8) Incident response playbooks (keep them short)</h2>
<ol>
  <li>Confirm scope: edge vs origin vs client-only.</li>
  <li>Check last deploy and config diff.</li>
  <li>Roll forward with fix or roll back static assets.</li>
  <li>Post-incident note: one paragraph, what changed, what prevented recurrence.</li>
</ol>

<h2>9) What not to do</h2>
<ul>
  <li>Do not build a custom metrics database on day one.</li>
  <li>Do not page humans for single 404s on weird paths.</li>
  <li>Do not measure 50 KPIs — three trends beat forty flat graphs.</li>
</ul>

<h2>Closing</h2>
<p>
  Static sites reward discipline: versioned assets, immutable deploys, and fast edges. Observability makes that discipline visible when something
  slips. Start with edge logs + client errors + a handful of RUM percentiles; expand only when those stop embarrassing you in production.
</p>