Outside-in checks that do not cry wolf

Flapping is a paging problem, not a monitoring problem

Every on-call rotation has the same story. A single probe location loses a packet to a transit provider for forty seconds, the check fails, the pager goes off, and an engineer who was asleep spends ten minutes confirming that nothing is wrong. After a few of those the team mutes the channel, and the next real outage is found by a customer.

Tenium treats one failed request as a hypothesis. The failing region marks the monitor suspect and asks other regions for an immediate second opinion. The monitor goes down and an incident opens only when all two regions report failure inside the confirmation window, which defaults to 60 seconds. Recovery is confirmed the same way, so a service that bounces between healthy and broken produces one incident with the transitions recorded inside it, not a string of open and close notifications.

Live regions today are Amsterdam and London, so the quorum is 2 of two. Two things follow from that and we would rather state them than let you find out. With a quorum of 2 regions, a failure visible from only one place is treated as local to that place, which is what you want for routing trouble and not what you want if you only serve one country that one probe is closest to. And a monitor you deliberately pin to a single region skips confirmation entirely and alerts on its first failure, which the UI labels clearly. The mechanics are written up in regions and confirmation and the longer essay how we confirm downtime.

Escalation that matches how rotations really work

Escalation policies arrive on Pro ($29). A policy is an ordered list of steps with delays: for example, a Telegram group immediately, an email to the primary after five minutes without acknowledgement, a Telegram message to the secondary after fifteen. Acknowledging from the Telegram button, the email link or the API stops the remaining steps. Recovery messages go to everyone who received the original alert.

On Agency ($59) PagerDuty and Zapier are available as destinations, so the incident can land in the tool that already owns your schedules and overrides. If you already run a PagerDuty rotation, treat Tenium as a source of confirmed external signals feeding it, and keep the Tenium-side escalation as the backup path for when the integration itself is down. The alert body carries the monitor, the error, which regions confirmed, the status code, a response excerpt and the resolved IP per region, so the person paged can tell a DNS problem from an application error before opening a laptop. Details live on the alert escalation and incident management pages.

Heartbeats for cron, CI and batch work

The jobs most likely to fail silently are the ones nobody watches: nightly backups, certificate renewals, queue sweepers, data exports, the scheduled pipeline that nobody has looked at since the migration. A heartbeat monitor inverts the usual direction. Instead of Tenium calling your service, your job calls Tenium, and the monitor goes down if the call does not arrive by its deadline.

• Append a single request to the job: curl -fsS -m 10 https://ping.tenium.app/h/abc123 > /dev/null
• Use the /start suffix before the job and the bare URL after to track duration; a job that starts and never finishes is flagged too.
• Call /fail from your error trap to open an incident immediately, with up to 10 KB of log tail attached.
• Set a period plus grace, or a cron expression with a time zone, so a nightly job at 03:00 is not judged on summer-time arithmetic.

Heartbeats start on Starter, with 20 there, 100 on Pro and 500 on Agency. See cron job monitoring and the heartbeat docs for every suffix and payload.

Deploys, maintenance and the API

Planned work should not count against uptime or wake anyone. Recurring or one-off maintenance windows are set in the app, with a time zone, and suppress alerts and exclude the period from reported uptime. For pipeline-driven rollouts the REST API gives you POST /monitors/{id}/pause and /resume, so a deploy job can pause the affected monitors, roll out, trigger POST /monitors/{id}/check to verify from outside and resume. Write calls need a write-scoped key on Pro or Agency; the limits are 120 write requests per minute per key and one on-demand check per monitor every ten seconds. The API overview has the endpoints and curl examples, and maintenance windows covers the scheduled kind.

Be clear on what Tenium is not. It does not collect internal metrics, run synthetic browser journeys or replace your tracing. It checks from outside what a customer would see, at as little as 30 s on Pro and Agency, and tells the right person once the evidence is solid.

Webhooks into your own plumbing

Signed webhooks on Pro send incident.opened, incident.acknowledged and incident.resolved events, plus expiry and response-time events, as JSON with an HMAC-SHA256 signature over the timestamp and body. Verify the signature, reject anything older than five minutes and you can fan events into chat ops, a ticket queue or a runbook automation without trusting the network path. Failed deliveries are retried five times over about half an hour. The payload shapes are in the webhook docs.