Uptime monitoring that fits into your code, CI and on-call tooling

API and CLI: monitoring as part of your workflow

Every Uptime Tracker plan, including Free, includes the REST API and the monctl command-line tool, so monitors can be created, changed and exported from code instead of only through the dashboard.

• REST API documented with an OpenAPI spec, so you can generate a client in your language or explore it with standard tooling.
• Scoped tokens per workspace with read or write access. Give CI a write token and dashboards a read-only one.
• Rate limit of 300 requests per minute, which comfortably covers provisioning and periodic syncs.
• monctl covers monitors, incidents, deploy markers, maintenance windows and exports.

Common uses:

1. Create monitors automatically when a new service, preview environment or customer instance is deployed, and remove them when it is torn down.
2. Open a maintenance window at the start of a migration script and close it at the end.
3. Export check results and incidents as CSV into your own analysis or reporting.
4. Keep monitor definitions in a repository and apply them from CI.

The dashboard updates live, so changes made through the API appear immediately for teammates watching it. API reference and examples live in the help center.

Deploy markers: connect incidents to releases

Deployment markers on Starter and Team record each release from your CI pipeline, and when an incident starts shortly after a deploy, Uptime Tracker shows that deploy next to the incident as possibly related. In practice this answers the first question in most incidents, "did we just ship something?", without anyone digging through CI logs.

Recipes are available for GitHub Actions, GitLab CI and Jenkins. The general pattern is the same in any CI system:

1. Create a workspace API token with write scope and store it as a CI secret.
2. Add a step after a successful deploy that calls the API or runs monctl to record a deploy marker for the release.
3. Optionally open a short maintenance window around deploys that cause expected downtime.

Markers are most useful when combined with fast checks on the service you just deployed: 60-second checks on Starter, 30 seconds on Team. A broken deploy then shows up as an incident within a minute or two, with the release that caused it already linked.

Correlation is shown as "possibly related", not as proof. A deploy that happens shortly before an unrelated provider outage will still appear, so treat it as a lead to check first.

Webhooks for your own automation

Signed webhooks, free on every plan, push monitor events to any HTTPS endpoint so you can trigger your own automation: open a ticket, post to an internal chat, restart a service, or feed events into your observability stack.

Each delivery carries an HMAC-SHA256 signature in a header of the form t=…,v1=…, where t is a timestamp and v1 the signature. Your receiver should:

• Recompute the signature with the webhook secret and compare it in constant time.
• Reject deliveries with timestamps outside the replay window.
• Respond quickly with a 2xx status and process the event asynchronously.
• Be idempotent, because failed deliveries are retried with backoff and may arrive more than once.

The exact payload and signing format are documented in the help center. For incident management, the Team plan also integrates natively with PagerDuty through Events API v2, for US or EU accounts, with de-duplication and automatic resolution. Every channel is listed on the integrations page.

Checks developers actually need

Uptime Tracker covers the protocols a typical backend exposes, with assertions strict enough to catch partial failures.

Monitors cannot target private or internal network addresses. For services inside a VPC or cluster, run a small job internally that checks them and pings a heartbeat, for example as a Kubernetes CronJob or a systemd timer. Details for each check are on the API monitoring and port monitoring pages.

Heartbeats in one line

Heartbeats are the fastest way to monitor scheduled and background work: append one HTTP call to the end of a job and get alerted when it stops arriving.

./run-migrations.sh && curl -fsS -X POST https://uptimetracker.live/api/v1/heartbeats/<token>

Key behavior to design around:

• Expected interval from 15 seconds to 1 hour, grace period from 0 to 60 minutes (default 5).
• Only success pings exist; there is no start or fail signal, so send the ping only when the job succeeds.
• Up to 10 accepted signals per minute per heartbeat.
• GET or POST both work, so any HTTP client in any language can send it.

Free includes 5 heartbeats, Starter 10 and Team 50.

For jobs that run daily or weekly, which exceed the 1-hour maximum interval, have an hourly task check the freshness of the job's output and ping only when it is recent. For long-running workers, ping from the main loop after each successful batch rather than on a timer, so a stuck worker stops pinging even though the process is alive.

Which plan fits developers?

Free is a complete toolkit for a side project or a single service: API, CLI, webhooks, heartbeats and HTTP, TCP and DNS checks. Starter adds what most production services need: deploy markers, authenticated requests with JSON assertions, 60-second checks and 72 hours of raw results for debugging. Team adds workflows, gRPC and mail checks, PagerDuty and on-call, 30-second checks and 7 days of raw history.

Because downgrades pause rather than delete monitors, you can trial Team for 14 days without a card and fall back to Free safely. Annual billing is 10 times the monthly price. See pricing for all limits.