17 — Monitoring and Observability Checklist#

Verify that critical services and user journeys can be understood through trustworthy telemetry, actionable alerts, service-level measurements, and effective incident investigation. Monitoring systems must also be reliable, proportionate, and privacy-conscious.

Scope: Frontend-specific. This file is one part of the 17_Monitoring_and_Observability.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• Critical services / user journeys:
• Monitoring and incident-response owners:
• SLI / SLO / alerting policy reference:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Copy the shared template into project-specific review records; leave all checkboxes in this repository unchecked.
2. Mark [x] only after verifying the item through instrumentation configuration, actual dashboards and queries, sample logs/traces, controlled alert tests, incident drills, or other documented evidence. Record failed checks and N/A reasons in project-specific notes or issue tracking keyed by OBS ID.
3. Identify user-critical journeys and their real failure modes before selecting metrics, alert thresholds, or telemetry vendors. Adjust monitoring depth to expected operational risk and staff coverage.
4. Review ## API Checks and ## Frontend Checks separately when relevant; record genuinely inapplicable checks outside the shared template.
5. Reassess instrumentation and alerts after deployments, new data flows, new critical features, incidents, and changes to support arrangements. Monitoring review is not a substitute for separate Security, Privacy, Reliability, or Performance reviews.

Frontend Checks#

• OBS-101 Capture real-user loading and interaction indicators for representative routes and supported device classes where appropriate.
• OBS-102 Measure applicable Core Web Vitals (LCP, INP, CLS) with sufficient context to separate important page types and user cohorts.
• OBS-103 Track JavaScript exceptions and unhandled promise rejections with release identifiers and useful non-sensitive stack information.
• OBS-104 Correlate frontend error reports with backend request or trace identifiers without exposing sensitive internal context.
• OBS-105 Record critical journey failures and completion outcomes that indicate user impact rather than only page views.
• OBS-106 Monitor API call failure rates and user-visible timeouts from the client perspective in addition to server-side metrics.
• OBS-107 Identify navigation or rendering failures introduced by CDN, edge cache, service workers, or stale asset versions.
• OBS-108 Monitor major variations in client performance across connection types, device capabilities, and browser families where sample sizes support them.
• OBS-109 Associate frontend telemetry with specific deployed versions and feature flags to detect release regressions.
• OBS-110 Configure source-map handling and access so diagnosis is possible without unintentionally exposing private source or secrets.
• OBS-111 Use consent-aware, privacy-conscious instrumentation and respect applicable collection restrictions.
• OBS-112 Exclude credentials, personal form content, authentication tokens, and sensitive URL parameters from client error and analytics reports.
• OBS-113 Protect telemetry endpoints against uncontrolled event floods, duplicate reports, and unbounded payload size.
• OBS-114 Bound frontend instrumentation CPU, memory, network, and battery impact and validate overhead under representative conditions.
• OBS-115 Check that client-side sampling preserves visibility into critical errors and does not turn rare failures invisible.
• OBS-116 Define alerting or triage thresholds for widespread client crashes, broken critical workflows, or severe page regressions.
• OBS-117 Test error capture for routed applications, hydration failures, resource load failures, and error boundaries when relevant.
• OBS-118 Ensure frontend monitoring does not block form submission, navigation, accessibility interactions, or offline recovery when telemetry fails.
• OBS-119 Provide an understandable manual problem-reporting route for users when automatic detection misses issues.

Release gate#

• Critical user journeys and dependent services have identifiable monitoring owners, useful health indicators, and working observability access.
• Service-level objectives or other accepted reliability expectations have clearly defined measurement and incident-detection methods where applicable.
• Meaningful user-impact alerts reach appropriate responders; alert routing, escalation, and at least one representative trigger have been tested.
• Logs, metrics, traces, and dashboard views needed to investigate a critical failure are usable, correlated where necessary, and tagged with the deployed version or environment.
• Telemetry pipelines report their own health or absence of data, and logging/monitoring does not expose prohibited sensitive information.
• API and frontend error, latency, and critical-journey indicators are reviewed where those interfaces exist, including known collection and sampling limits.
• Incident response roles, escalation procedures, relevant runbooks, and unresolved observability gaps have accountable owners and authorized dispositions in project-specific records.

Domain-specific approval rule: Block monitoring sign-off if a critical user-impacting failure cannot reasonably be detected or investigated, required alerts do not reach responders, monitoring is materially blind without accepted mitigation, or sensitive telemetry exposure remains unresolved. Dashboard existence alone does not establish production observability.

Trusted references and scope#

These checks translate authoritative observability and operations guidance into practical verification tasks. They do not mandate a specific vendor, instrumentation SDK, or SLO target.

• OpenTelemetry — Signals — core telemetry concepts and selecting logs, metrics, and traces.
• OpenTelemetry — Semantic conventions — consistent operation, resource, metric, log, and trace attributes.
• OpenTelemetry — Logs — structured logging, stable schema, and correlation.
• OpenTelemetry — Handling sensitive data — data minimization, redaction, and telemetry privacy.
• OpenTelemetry — Collector resiliency — telemetry queueing, exporter failures, and data-loss controls.
• Google SRE — Monitoring Distributed Systems — four golden signals and symptom-driven monitoring.
• Google SRE Workbook — Monitoring — service and dependency signals and operational dashboards.
• Google SRE Workbook — Alerting on SLOs — error-budget and multi-window burn-rate alerting.
• Google SRE Workbook — Postmortem Culture — blameless incident learning and follow-up ownership.
• Prometheus — Alerting best practices — actionable, user-impact-focused alerts and monitoring of monitoring.
• Prometheus — Alerting rules — alerting thresholds, pending durations, labels, and annotations.
• Grafana — Alerting best practices — routing, severity, useful alerts, and alert noise management.
• web.dev — Web Vitals — client-side loading, interactivity, and layout stability metrics.

Applicability: Monitoring requirements depend on the service's criticality, traffic, architecture, user population, jurisdiction, and available operational coverage. Tracing across distributed services, browser Web Vitals, SLO burn-rate paging, and OpenTelemetry Collector configuration are conditional, not universal. Sample size and low-traffic behavior must be considered before configuring percentage-based alerts. Keep sensitive personal, financial, health, and credential data out of broadly visible telemetry.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: trace propagation, metrics/logs, alert conditions, and SLO visibility; include browser and client behavior where applicable.
• Cross-stack: Prometheus promtool + OpenTelemetry.
• Python: OpenTelemetry + pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: OpenTelemetry + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: OpenTelemetry + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• observability-and-instrumentation — Check telemetry and diagnosis coverage (addyosmani/agent-skills, 116,378 repo stars).
• distributed-tracing — Check tracing across service boundaries (wshobson/agents, 42,437 repo stars).
• slo-implementation — Review alerting and objective measurements (wshobson/agents, 42,437 repo stars).

How to check: In a project-specific copy, have the agent audit the frontend scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.