External uptime monitoring

Know when your service fails—and when it recovers.

Monitor websites, APIs, DNS names, and TCP services from your configured Sentinely region. Keep every check, incident, and recovery in one timeline.

First monitor takes minutes · verify alerts during the trial

HTTP and HTTPS

Check status codes, response time, optional response text, headers, and request bodies.

TCP and DNS

Verify a TCP port accepts connections or a hostname resolves from the configured check region.

One-minute intervals

Paid plans can schedule checks every minute, with atomic leases preventing duplicate workers.

TLS certificate tracking

Record certificate validity and alert as an HTTPS certificate approaches expiration.

Down and recovery alerts

Send incident and recovery notifications by email and the configured Slack integration.

Incident history

Keep response-time checks, failure causes, recoveries, and uptime history together.

Failure lifecycle

Avoid one-off alert noise.

Configure a failure threshold, open one incident after repeated failures, and close it automatically on recovery. Alert delivery errors are recorded without losing the incident itself.

A due monitor is leased by one worker
The target is checked with a bounded timeout
Repeated failures open one incident
Recovery closes the incident and notifies the team

Put selected monitors on your public status page.

Share live component status without exposing private monitor URLs, credentials, or internal metadata.

Create your first monitor