Get Started
From zero to monitored in minutes
Follow this guide to create an account, add your first monitor, understand how SentinelMesh verifies incidents, and configure your alerts — no noise, no spam.
Create an account
SentinelMesh is self-hostable. If your team manages its own deployment, you'll receive an invite link. Otherwise, sign up on the platform hosted by your admin.
Add your first monitor
A monitor defines the endpoint to check, how often to check it, and who to notify. Every monitor runs on its own cadence and produces an independent stream of check results.
From your dashboard, click "New Monitor".
Enter the URL you want to watch.
Use your health-check endpoint (e.g. /health or /ping) for the most reliable signal.
Set a check interval — e.g. every 1 minute.
Add your alert email (Step 4 covers this in detail).
Save. The scheduler picks it up within seconds.
How verification works
A single failed HTTP check does not trigger an alert. SentinelMesh uses a consecutive failure threshold to distinguish blips from real outages.
Stage 1 — Blip detection
One failed check is logged but ignored. Network hiccups happen.
Stage 2 — Confirmed outage
Two or more consecutive failures confirm a real outage. An incident opens and your alert fires — exactly once.
State transitions
Configure alerts
Alerts are state-based, meaning they fire exactly once per transition. No repeat emails during an ongoing outage. No alert storm on recovery.
Open the monitor editor for any existing monitor.
Fill in the Alert Email field with your on-call address.
Use a distribution list for team-wide alerts.
Save changes.
What emails you'll receive
Incident opened
Sent once when monitor transitions to DOWN
Incident resolved
Sent once when monitor recovers to UP
Read your dashboard
Once monitors are running, your dashboard gives you a live view of uptime health, recent check results, and open incidents.
Dashboard panels
Monitors overview
At-a-glance status for every endpoint: UP, DOWN, or DEGRADED. Click any row to drill into its check history.
Check result timeline
A time-series log of every HTTP check result — status code, latency in ms, and timestamp. Powered by TimescaleDB for fast range queries.
Active incidents
Open incidents listed with opened-at timestamp and duration. Resolves automatically when checks pass.
Architecture overview
Every check you set up flows through six discrete, stateless components. Understanding the pipeline helps you reason about data freshness and latency between check and alert.
Reads all active monitors and enqueues a BullMQ job per monitor on the configured cadence. Jobs are deduplicated by ID — so a scheduler restart never creates duplicate checks.
Stateless processes that dequeue jobs, run the HTTP check, and write the result. Scale horizontally by adding workers — no leader election, no shared state.
Every result is written as an immutable row in TimescaleDB. Nothing is overwritten. You have a forensic log of every check ever run.
Reads the latest N results per monitor per region. Applies the state machine: if consecutive failures ≥ threshold, escalate. Confirms before acting.
Created once per distinct outage. Stores region, opened-at, and resolved-at. Not duplicated even if Verifier runs multiple times.
Fires one email on DOWN transition, one on UP recovery. State-based: no repeat alerts for the same open incident.
Coming in V2
- Multi-region verification
- Workers in Frankfurt, Virginia, and Mumbai. Quorum-based confirmation (2/3 regions) before any alert fires.
- WhatsApp alerts
- Notifications where your team actually is.
- Status pages
- A public URL your users can check themselves.
- Performance metrics
- p50, p95, p99 response times per monitor.
Ready to stop firefighting false positives?