Monitoring Implementation Map

/monitoring is a thin shell (app/routes/monitoring._index.tsx → app/pages/monitoring/MonitoringPage.tsx) hosting two independently-owned panels selected by ?view=uptime|errors (defaults to uptime). navigation mirrors it as view="monitoring" with monitoringView (plus monitorId/errorIssueId when a row is open); each panel also writes richer selection to the monitoring application-state key.

Uptime

• UI: app/pages/monitoring/UptimePanel.tsx, app/pages/monitoring/uptime/**.
• Server: server/lib/uptime-monitors.ts (checks/alerting), sweep job server/jobs/uptime-monitors.ts, scheduler server/plugins/uptime-monitor-jobs.ts, schema server/db/schema-monitoring.ts.
• Actions: list-monitors, get-monitor, save-monitor, run-monitor-check, delete-monitor.
• Production serverless/Netlify-style runtimes skip the in-process interval scheduler and rely on the generated scheduled/background worker or external cron instead.
• Deep links: list ?view=uptime, detail ?view=uptime&monitor=<id>, create ?view=uptime&monitor=new, edit ?view=uptime&monitor=<id>&edit=1.
• See docs/uptime-monitoring.md.

Status Pages

• UI: app/pages/monitoring/uptime/status-pages/**, a config sub-view under Uptime that bundles chosen monitors under a public /status/<slug> page.
• Server: owner-scoped CRUD and the sanitized public projection live in server/lib/status-pages.ts over server/db/schema-monitoring.ts.
• Actions: list-status-pages, get-status-page, save-status-page, delete-status-page, add-status-page-monitor, remove-status-page-monitor, reorder-status-page-monitors, plus the unauthenticated get-public-status-page.
• Deep links: index ?view=uptime&statuspage=list, create ?view=uptime&statuspage=new, edit ?view=uptime&statuspage=<id>.

Errors

• UI: app/pages/monitoring/ErrorsPanel.tsx, app/pages/monitoring/errors/** — first-party, Sentry-style exception triage grouped into issues by fingerprint.
• Server: ingest/grouping in server/lib/error-capture.ts over server/db/schema-errors.ts.
• Browser exceptions arrive through configureTracking() as $exception events; server captureError() failures arrive through the shared tracking provider when the server Analytics key is configured and use the same grouped issue store.
• Actions: list-error-issues, get-error-issue, resolve-error-issue, capture-test-error, match-error-issues.
• Browser capture uses the SDK from @agent-native/core/client (captureException / captureMessage / addErrorBreadcrumb), auto-enabled by configureTracking and transported through the first-party analytics ingest as a $exception event.
• Test identities (QA/E2E accounts, isTestIdentity) keep their exceptions: occurrences are flagged testIdentity, never count toward users affected, and never alert. An issue only they have hit is testIdentityOnly and hidden from list-error-issues unless includeTestIdentities: true; the new-issue alert fires on its first real-user occurrence instead. Ingest decides from the identities an event carries (userId, email fields, its context), never from a sender's test_identity flag, which any write-key holder could set.
• Deep link: ?view=errors&issue=<id>. Issue detail includes recent frequency, parsed/raw stack traces, source code snippets when available, breadcrumbs, tags, occurrence history, and session replay links.
• Agent lookup: call list-error-issues first, then get-error-issue for stack, occurrence, and replay detail. These are separate from the external Sentry action and do not require a Sentry credential.
• See docs/error-capture.md.

Session Replay ↔ Errors

A recording's devtools Console error lines link to the grouped issue at /monitoring?view=errors&issue=<id>, resolved by match-error-issues (exact fingerprint match, no heuristics); issues link back to the originating recording at /sessions/<recordingId>. The fingerprint includes the app, so match-error-issues takes the recording's app and only matches issues filed under it.

Related Skills

• session-replay — replay storage, capture, and the Dev Tools panel this feature links to.