Skip to main content
The monitors list in the Sentivel dashboard
A monitor checks one thing on a schedule. When it fails enough times in a row, Sentivel opens an incident on the component it’s attached to and pages whoever’s on call. One failed check on its own never opens an incident.

​
Monitor types

An SSL warning goes to your team as an internal alert and opens no public incident, since an expiring certificate isn’t an outage yet.

​
Add an HTTP monitor

  1. Go to Monitors and click Add a monitor.
  2. Enter the URL to check and the method.
  3. Set what counts as healthy: expected status codes, an optional keyword, an optional response-time threshold.
  4. Attach it to a component (or let Sentivel create one).
The first check runs on the next poll cycle, within about two minutes. Until a new monitor has its first run of healthy checks, its component reads “warming up”.
A monitor’s target is fetched from our servers on every poll, so it must be a public http(s) address. Private, loopback, link-local, and cloud-metadata hosts are rejected, and redirects are re-checked per hop.

​
Add a heartbeat

  1. Go to Monitors, click Add a monitor, and choose Heartbeat.
  2. Set the Expected interval (how often a ping should arrive) and the Grace period (extra time before a late ping counts).
  3. Choose what happens When pings stop:
    • Mark it down. For scheduled jobs. A missed ping opens an incident and pages whoever’s on call.
    • Show it as idle. For scripts and apps that only ping while someone is using them. A missed ping opens no incident and records no downtime. The component reads Idle until the next ping, and a status page where nothing is running reads No recent activity.
  4. Call the ping URL from your job. Sentivel shows it once the monitor is created, with snippets for cron, Node.js, Python, and Lua.
A heartbeat reads Awaiting first ping until a ping arrives at least one interval after you create it, so a test ping during setup never counts as a job that later stopped.
The ping URL is a credential. Anyone who has it can send pings, so keep it out of public repositories. If it leaks, click Regenerate on the monitor’s page; the old URL stops working immediately.

​
Flap thresholds

Two settings control when an incident opens and closes:
  • Open after N consecutive failures. Higher means fewer false alarms, slower detection.
  • Resolve after N consecutive successes.
A recovery that doesn’t meet the resolve threshold stays the same incident. A confirmed resolution followed by a fresh run of failures is a new one.

​
Intervals, pausing, and maintenance

Set how often each monitor runs. Pause a monitor to stop checks without deleting it. Put a monitor (or a whole workspace) into a maintenance window to skip checks during planned work. Skipped checks open no incident and don’t count against uptime.

​
Maintenance from the API

Your deploy script can put a monitor into maintenance. Its checks pause and its public component reads “under maintenance”.
Open-ended (cleared when you're done)
Send an empty body for open-ended maintenance when you don’t know how long the work runs. Pass until (ISO 8601) for a window that auto-expires.
Bounded window
End maintenance with DELETE. Checks resume on the next poll.
End it
Over MCP, the same is sentivel_start_maintenance and sentivel_end_maintenance.

​
Response times

Every monitor records how long each check took, split into the four parts of a request, so you can see which part is slow. The four add up to the total response time. If only DNS climbs, look at your resolver. If only waiting climbs, look at the service itself. The chart on a monitor’s page shows the split, with the numbers for any point on hover. Pick a window with the period selector, and filter to one probe region on a multi-region monitor.
The breakdown is on the Solo plan and above. Every plan measures and stores it, so after an upgrade you see the history your workspace has already collected.
Over the API it’s the phases object on each bucket from GET /monitors/{id}/response-times, or sentivel_get_monitor_response_times over MCP. A band that wasn’t measured is null (never 0).

​
Uptime

Sentivel keeps a daily uptime rollup per monitor, so the 90-day history on your status page survives even as raw check data ages out.