Create uptime monitors

Uptime monitors check whether important endpoints and services are reachable and healthy. Create monitors for the customer-facing and dependency endpoints your team needs to know about during incident response.

Before you create

Decide what success means before opening the drawer. A useful monitor checks a specific endpoint, from useful regions, with assertions that match the service's real health signal.

• Prefer health or readiness endpoints over pages with unrelated dependencies.
• Use production environment labels for customer-facing checks.
• Choose alert thresholds that avoid one-off network blips but still catch real outages.

Endpoint

The endpoint step defines what Errorgap checks and how to reach it.

• Check type: choose HTTPS, HTTP, TCP, or ping.
• Display name: use a short name responders recognize in tables and incidents.
• URL: enter a full URL for HTTP(S), or the host target for TCP and ping checks.
• Request method: choose GET, POST, or HEAD for HTTP(S) checks.
• Environment: optionally label the monitor, such as production or staging.

Schedule

The schedule controls check frequency, regions, and timeout. Shorter intervals detect issues faster but create more noise if the endpoint is flaky.

• Use 30 seconds or 1 minute for critical production endpoints.
• Use 5 or 15 minutes for lower-priority dependencies or staging checks.
• Select regions that represent where customers or dependencies access the service.
• Set timeout high enough for normal slow responses but low enough to detect degraded service.

Assertions

Assertions decide what counts as healthy. The default expected status of 200-299 works for most HTTP(S) health endpoints.

• Use a status range such as 200-299 for normal success responses.
• Use a comma-separated list when only specific statuses are acceptable.
• Add Response must contain only when the body includes a stable health keyword.

Alerting

Alerting controls when failures become incidents and which channels should be notified.

• Alert after sets how many consecutive failed checks open an incident.
• Notify selects destinations such as email, Slack, PagerDuty, or webhooks.
• Warn before SSL expiry marks HTTPS monitors degraded before a certificate expires.

Edit, pause, or delete

Open a monitor detail page when a check needs maintenance. Use edit for real configuration changes, pause for temporary maintenance windows, and delete only when the monitor and its history are no longer useful.

• Pause a monitor before planned downtime that should not page responders.
• Resume the monitor as soon as the endpoint should be healthy again.
• Edit assertions when the service's health response changes.
• Delete monitors carefully because deletion removes monitor history and alert rules.

Validation checklist

1. Create the monitor and wait for the first check to run.
2. Confirm the status is operational for a known healthy endpoint.
3. Open monitor detail and review recent checks.
4. Confirm alert destinations are correct for the owning team.
5. Review the monitor after the next deploy or maintenance window.