Pagewell PRD, brand kit & board

The market is crowded with operating products covering the whole job: automatic uptime checks, alerts and a status page. Closest to the indie SaaS target are StillOnline (HTTP checks, incidents, Telegram/Slack/email alerts, $0/$9/$29 plans), SiteReady (HTTP checks, email alerts, public status page, from $0), PingPing (30-second checks, Slack/email/SMS, status pages), Pulsetic (multi-region checks, many alert channels, status pages from $9/mo) and Cronaut (automatic incident creation on a status page, email/Slack alerts). Larger or broader tools such as UptimeRobot, StatusCake, Oh Dear, Better Stack, Instatus and openstatus cover the same parts at broader scope, and Gatus and Uptime Kuma cover them as self-hosted open source. StatusPal covers status pages and integrated monitoring. No claim is made that no tool does this job; the phrase searches returned incomplete results. No named-tool or phrase searches failed.

frontend

Next.js (App Router); status page and badge server-rendered.

backend

Next.js route handlers for app, badge, billing webhooks. Separate always-on Node worker for checks and alerts, because 1-minute checks with 15-second retries need a persistent scheduler, not serverless functions.

database

Supabase Postgres. Row-level security on every table; the worker and public pages use the server-side service role.

auth

Supabase Auth, email and password or magic link.

llm

Not required. Detection, the retry and recovery rules, incident open and close, and every alert, status-page and badge message are deterministic logic and templates filled with stored values. A model would add cost and risk of wrong public statements.

infra

Vercel for the web app. Worker on a small container host (Fly.io or Railway) [assumption], with at least 2 worker instances later; the claim lease makes this safe. Transactional email provider (Resend or Postmark) [assumption]. Billing: Stripe [assumption] behind a BillingProvider interface because plans and pricing are still open. Third parties receiving user data: Supabase, Vercel, the worker host, the email provider, Stripe, and Slack (only the owner's own channel). Slack webhook URLs are encrypted in alert_channel_secrets and readable only by the service role.

devtools

TypeScript, Supabase CLI migrations, Vitest, Playwright, a local mock HTTP server for failure scenarios.

• Detection and incident engine (worker, core job)

  INPUTS: monitors that are due (next_check_at <= now(), paused_reason IS NULL, owner subscription status in trialing/active/past_due) and the worker canary result. OUTPUTS: checks rows, monitors state updates, incidents, incident_updates, notifications rows (an outbox), incident_feedback_links. APPROACH: (a) Claim due monitors in batches with a single UPDATE ... WHERE id IN (SELECT ... FOR UPDATE SKIP LOCKED) that sets locked_until, so two workers never check the same monitor. (b) Run each check with a timeout of timeout_seconds [assumption: 10s]. Up means a final response of 2xx or 3xx after at most 5 redirects [assumption]; anything else is down with failure_reason in timeout, dns_error, connection_error, tls_error, http_status or too_many_redirects. (c) False-positive guard: on a failed check increment consecutive_failures, set first_failure_at if null, and reschedule the same monitor in 15s [assumption] instead of waiting a full interval. Open an incident only when consecutive_failures reaches 3 [assumption: first check plus 2 retries], so one dropped request never opens one. Any success resets consecutive_failures to 0. (d) Open incident in ONE transaction: insert the incident (started_at = first_failure_at, so alert latency is measured from the first failed check), set open_monitor_id, set monitors.current_state='down', insert an incident_updates row (kind 'auto_opened', templated message), insert one notifications row per enabled alert channel (event_kind 'opened', status 'pending', idempotency_key = incident_id:channel_id:opened), and insert incident_feedback_links. (e) Resolve: while current_state='down', 2 consecutive successes [assumption] set status='resolved', resolved_at, open_monitor_id=NULL, and add an 'auto_resolved' update plus 'resolved' notifications, all in one transaction. One success is not enough, to avoid flapping. (f) Canary: each cycle the worker checks 2 stable public endpoints [assumption]. If both fail, the worker's own network is suspect, so it records worker_heartbeats.canary_ok=false, does not count that cycle's failures, and does not open or resolve incidents. (g) Targets that resolve to private, loopback or link-local addresses are never fetched (SSRF block, DNS answer pinned for the request, re-validated on every redirect). Such a monitor gets paused_reason='blocked_target' and never counts as downtime. NEVER VIOLATE: an incident opens only after 3 consecutive confirmed failures with a healthy canary; at most one open incident per monitor (enforced by UNIQUE open_monitor_id); a monitor is never resolved or opened from stale data (a worker that has missed its heartbeat does not decide anything); the same alert is never sent twice. This logic is fully deterministic. KNOWN LIMIT: one worker region means a regional network problem between the worker and the customer can look like downtime. Multi-region checks are out of scope, so the canary and retries are the only protections.

• Alert dispatcher (worker)

  Polls notifications with status 'pending' and sends them. Email goes to the owner's account email through a transactional email provider. Slack goes to the channel's webhook URL, decrypted from alert_channel_secrets at send time. Success sets status='sent' and sent_at. Failures are retried with attempts incremented up to a cap [assumption: 5], then status='failed' with last_error. Email and Slack are independent, so a Slack failure never blocks the email. The unique idempotency_key makes retries and worker restarts safe. Message bodies are templates filled with monitor name, URL, failure_reason, started_at and resolved_at. The open email includes one-click 'real outage' and 'false alarm' links.

• Status page renderer

  Public server-rendered page at /s/{slug} (path scheme is an assumption). It shows overall status and the incident history from incidents and incident_updates, including owner notes. Overall status is derived deterministically: any open incident means down; all monitors up means operational; otherwise no data yet. Reads use the service role with an explicit column list, never exposing alert channels, secrets, or owner data. Owner note text is rendered as escaped plain text.

• Embeddable badge endpoint

  GET /badge/{slug}.svg returns a small SVG showing current up/down status only (default for the open badge question), derived the same way as the status page. Short cache headers [assumption: 60 seconds]. The dashboard shows copyable Markdown and HTML snippets. Image proxies such as the ones READMEs use may cache longer, so the badge is 'near-live', not instant.

• Dashboard and guided onboarding

  Signup, then project name and slug, then first monitor URL, then a live status page link and badge snippet, in one guided flow with defaults (60s interval, email channel auto-created). Sets profiles.onboarding_completed_at. Also manages monitors, pausing, alert channels (including connecting Slack), and adding an owner note to an open incident.

• Incident notes

  Lets the owner add a short plain-text update to an open or resolved incident. It writes an incident_updates row with kind 'owner_note', shown on the status page.

• Feedback link handler

  Handles one-click verdict links from the open-incident email. The raw token is only in the email; incident_feedback_links stores token_hash. Visiting a valid, unused, unexpired link sets incidents.owner_verdict and used_at. This produces the real-outage rate success metric.

• Billing and entitlements

  Self-serve checkout and plan changes behind a BillingProvider interface (default Stripe [assumption]). A webhook handler inserts billing_events (unique provider + provider_event_id, so replays do nothing) and updates subscriptions. Monitor creation enforces plans.monitor_limit. A canceled subscription stops checks and alerts via the worker eligibility rule.

• Worker health watchdog

  Worker writes worker_heartbeats.last_beat_at each loop. An external uptime ping on the worker's health endpoint (a separate service from Pagewell itself) alerts the founder if beats stop, because a dead worker silently produces no incidents at all.