Build · Create · Engineering
Alert rule register (with runbook links)
A deduplicated alert rule set where every paging alert links a runbook, cutting alert fatigue and giving on-call an immediate response path.
You receive: A structured alert register (JSON) that passes the rule-shape, severity, paging-runbook, dedup, channel, and no-duplicate checks.
Part of Keep App Running
Example
A sample of what this play produces. Your result is generated for your inputs.
- Service
- stud.com production (Next.js platform app on Vercel, Neon Postgres)
- Notes
- Register for STUD.com's soft-launch production stack. Dedup group keys collapse storms per subsystem so one incident produces one page. Only critical pages a human, and every critical rule carries a runbook reference so on-call (a single founder-operator) has an immediate response path.
- Id
- web-5xx-rate
- Signal
- http_5xx_rate_pct
- Comparator
- gt
- Threshold
- 2
- Duration Minutes
- 5
- Severity
- critical
- Notify Channels
- pager
- slack
- Group Key
- web-availability
- Runbook Ref
- runbook:web-5xx-triage
- Rationale
- Sustained 5xx on stud.com means buyers cannot browse or run plays. Pages the founder-operator; the runbook starts with the Vercel rollback path (the preview SPA is the documented fallback).
- Id
- web-p95-latency
- Signal
- http_p95_latency_ms
- Comparator
- gt
- Threshold
- 1500
- Duration Minutes
- 10
- Severity
- warning
- Notify Channels
- slack
- Group Key
- web-availability
- Runbook Ref
- runbook:latency-triage
- Rationale
- Slow catalog pages degrade the search-first funnel before they break it. Warning only, grouped with web-availability so a latency storm dedups against an active 5xx page.
- Id
- db-connection-saturation
- Signal
- neon_active_connections_pct
- Comparator
- gte
- Threshold
- 85
- Duration Minutes
- 5
- Severity
- critical
- Notify Channels
- pager
- Group Key
- database
- Runbook Ref
- runbook:neon-connection-saturation
- Rationale
- Neon connection exhaustion takes down every play page at once. Pages before the pool is fully saturated; the runbook covers pooling config and killing idle deploy-migrate sessions.
- Id
- deploy-migrate-failure
- Signal
- deploy_migrate_failures_count
- Comparator
- gte
- Threshold
- 1
- Duration Minutes
- 0
- Severity
- critical
- Notify Channels
- pager
- slack
- Group Key
- deploys
- Runbook Ref
- runbook:deploy-migrate-failure
- Rationale
- The production build runs schema migrate plus catalog sync before new code serves; one failure means prod schema and code can diverge. Zero-duration: a single failure pages immediately.
- Id
- judge-queue-backlog
- Signal
- judge_pending_runs_count
- Comparator
- gt
- Threshold
- 25
- Duration Minutes
- 15
- Severity
- warning
- Notify Channels
- slack
- Group Key
- judge
- Runbook Ref
- runbook:judge-backlog
- Rationale
- A growing acceptance-check backlog delays every deliverable landing. Warning at 25 pending for 15 minutes, sized to the soft-launch concierge capacity of about 30 plays a week.
- Id
- waitlist-signup-failures
- Signal
- waitlist_signup_error_count
- Comparator
- gt
- Threshold
- 3
- Duration Minutes
- 30
- Severity
- info
- Notify Channels
- Group Key
- growth-funnel
- Runbook Ref
- runbook:waitlist-form-triage
- Rationale
- During soft launch the waitlist is the whole conversion funnel. Info tier: it never pages, but a half hour of failed signups is lost demand worth a same-day look.
Opens soon
STUD opens runs for everyone soon, on every play at once.
Scope of the check
What's verified: STUD verifies the submitted register (JSON) is well-formed and deduplicated: every rule has a signal, a valid comparator, a numeric threshold and non-negative duration, a severity in your set, and channels from your allowed list, every paging-severity rule carries a runbook link, and no two rules share the same signal, comparator, threshold, and duration. STUD does NOT connect to your metrics or judge whether the thresholds are the right ones; it checks the register's structure.
Get early access to STUD the day it goes live.