Observability vs monitoring
Related service Website & online shop
DEFINITION
Monitoring answers pre-defined questions: is the server alive, is CPU above 80, is checkout p95 latency under 500 ms. It alerts when a known metric leaves its band. Observability is the inverse: it collects rich data layers (three pillars · metrics, logs, traces, plus events and profiles) that let you answer questions you had not thought to ask, after the fact, without redeploying. So: monitoring tells you something is wrong, observability tells you why this specific checkout failure had 7 hops in its trace and stalled at this downstream service. Translation in practice: Prometheus plus Grafana is monitoring, OpenTelemetry plus Tempo plus Loki plus Jaeger is observability. In 2026 OTel is the vendor-neutral default; commercial backends (Datadog, Honeycomb, New Relic) sit on top of it.
- SSR (Server-Side Rendering)→
HTML rendered by the server per-request, fresh for every user. Ideal for dynamic content (dashboards), but slower than SSG.
- SSG (Static Site Generation)→
Pages are produced at build time as HTML and served from a CDN. Near-zero TTFB. DField's own site runs this way across 111+ pages.
- ISR (Incremental Static Regeneration)→
SSG + timed regeneration: the HTML is static but regenerates on a schedule. Ideal for blog content · freshness with CDN speed.
- Edge rendering→
Code runs at the CDN edge closest to the user (Cloudflare Workers, Vercel Edge). Dynamic responses with ~10–50 ms TTFB.
- RSC (React Server Components)→
React components that run exclusively on the server and never ship to the browser. Result: less client-side JS and faster hydration.
- LCP (Largest Contentful Paint)→
Time until the largest visible element paints. Google Core Web Vitals passes under 2.5s · we usually land marketing pages under 1s.