Monitoring and Sentinel
How the 24-hour launch-window watcher and always-on Sentinel sampling work together.
Guides
Monitoring and Sentinel
A pre-flight check is a snapshot: it proves the launch path worked at one moment. Real launches fail after that moment — a webhook secret rotates, a deploy promotes a broken build, a provider quota runs out at 2 AM. PreFlight has two watchdogs for the time after the check passes.
Monitoring covers the fragile launch window with dense, time-boxed sampling. Sentinel keeps always-on production sampling after that window closes. Use both, in that order.
At a glance
| 24-hour Monitoring | 24/7 Sentinel | |
|---|---|---|
| Purpose | Release-window watcher | Continuous production sampling |
| Duration | Fixed 24 hours, then completes | Runs until paused or disabled |
| When to start | Before launch or after a risky deploy | After Monitoring, for ongoing coverage |
| Cadence | Denser samples during the window | Configurable per project (minutes) |
| Dashboard | /dashboard/monitoring | /dashboard/sentinel |
| Alerts | After repeated failures in the window | After crossing the failure threshold |
Use both, in order
The clean pattern is: run a full check, start Monitoring for the launch window, then enable Sentinel so the project stays watched after the 24 hours end.
24-hour Monitoring
Monitoring is the time-boxed release-window watcher. It samples the project's health endpoint and connected providers with denser cadence than Sentinel, routes alerts on repeated failures, and closes automatically after 24 hours.
Start a session
Open Monitoring. Choose the project whose release window you want to watch — workspace view at
/dashboard/monitoringor the project tab at/dashboard/projects/:id/monitoring.Start a session. PreFlight creates a running session with an
ends_attimestamp 24 hours ahead.Watch the samples. Each sample records status, response time, and timestamp. Repeated failures trigger alerts through your configured channels.
Let it complete. When the session expires, status moves to completed. Sample history remains in the Flight Recorder.
What each sample records
| Field | Meaning |
|---|---|
| Status | success, warning, or failed for each health sample |
| Response time | Per-sample latency to spot slow-burn regressions |
| Sample history | Full timeline for the window, persisted after completion |
| Alerts | Notifications sent after repeated failures, visible in Alerts |
Monitoring is not a replacement for full Pre-Flight Checks. Run a complete check before starting a session so you know the baseline is clean.
24/7 Sentinel
Sentinel is always-on production monitoring. Once enabled for a project, it samples on a configured cadence until you pause or disable it.
Per-project controls
| Setting | What it controls |
|---|---|
| Enabled | Whether Sentinel samples this project at all |
| Paused | Temporarily stop sampling without losing configuration |
| Cadence (minutes) | How often Sentinel runs the next sample |
| Failure threshold | Consecutive failures required before an alert and incident |
| Last sample / Next sample | When Sentinel last ran and when it will run again |
Sentinel requires a reachable health or webhook URL saved on the project. If samples are not appearing, confirm the URL, that the project is not paused, and that cadence is set.
How samples become incidents
A single failed sample is noise. Repeated failures are signal. When Sentinel crosses its failure threshold:
- The failure groups into an Incident in Incident Command.
- An alert delivers to configured Slack, Discord, email, PagerDuty, OpsGenie, Teams, or webhook channels.
- The event writes to the Flight Recorder with first-seen and last-seen timestamps.
- If Deploy Gates require healthy Sentinel, the gate blocks until the sample recovers.
Sentinel and Deploy Gates
A Deploy Gate can require an active, healthy Sentinel before a release is allowed. That turns continuous monitoring into a hard release control — see Deploy Gates.
The monitoring cron
Both watchdogs depend on an external scheduler calling the monitoring cron endpoint. The hosted setup uses a 10-minute Vercel Cron cadence to match the default health-sample window and failure logic.
/api/cron/monitoringBearer-authenticated scheduler that samples active Monitoring sessions, due Sentinel projects, Revenue Ledger Watch, custom checks, and Vercel Watch conditions.
Required environment variables:
| Variable | Purpose |
|---|---|
CRON_SECRET | Bearer token the scheduler sends |
SUPABASE_SERVICE_ROLE_KEY | Server-side persistence for samples and alerts |
RESEND_API_KEY + sender settings | Email alerts when email channels are enabled |
If samples are not appearing, verify the cron is scheduled, CRON_SECRET matches, and the project has a reachable URL. Full cron behavior is documented in Monitoring cron.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| No samples appearing | Cron not scheduled or wrong CRON_SECRET | Confirm Vercel Cron (or your scheduler) calls /api/cron/monitoring every 10 minutes |
| Sentinel never alerts | Failure threshold too high | Lower the threshold or shorten cadence |
| Alerts too noisy | Threshold too low or cadence too short | Raise threshold or lengthen cadence |
| Session ended | Monitoring is 24 hours by design | Enable Sentinel for ongoing coverage |
| Samples show skipped | No health URL on project | Save the project URL in Settings |