Skip to main content

monitoring

Implementation map for the Monitoring tab (uptime checks, public status pages, error triage): component/server file locations, schema, jobs, and scheduler wiring. Use when building or debugging Monitoring UI, uptime checks, status pages, or error capture/grouping โ€” not when just calling the monitoring actions from chat.

Source facts

Repository
BuilderIO/agent-native
Last source activity
October 2, 2026 at 23:40
Detected SKILL.md language
English
Stars
7,065
Forks
640

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions ยท Read-only preview
name
monitoring
description
Implementation map for the Monitoring tab (uptime checks, public status pages, error triage): component/server file locations, schema, jobs, and scheduler wiring. Use when building or debugging Monitoring UI, uptime checks, status pages, or error capture/grouping โ€” not when just calling the monitoring actions from chat.
scope
dev
# 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.
View on GitHub