Monitoring services

A service is a thing you monitor. Add one under Services → Add service.

Check types

HTTP(S)

Enter a full URL (https://example.com). The check passes on a 2xx/3xx response. Optionally set an expected HTTP status to require an exact code (for example 403 if that is the healthy response for an endpoint).

HTTP + keyword

Like HTTP, but the response body must also contain the expected keyword. Use it to confirm a page actually rendered, not just returned 200.

TCP port

Enter a host and optional port as host:port (for example db.example.com:5432). If you omit the port, it defaults to 80. IPv4, hostnames and IPv6 ([::1]:443 or bare ::1) are supported. The check passes if the TCP connection is established.

Timing and status

• Interval — how often the check runs (minimum 10 seconds).
• Timeout — how long to wait before a check counts as down.
• Degraded above (ms) — optional; if a response is slower than this, the service is marked degraded instead of operational.

Each run is recorded, and 90 days of history drive the uptime bars on the public page. Hover a bar to see that day's uptime, failed-check count, and any incidents that affected the service.

Pausing and deleting

Pause a service to stop checking it without losing history. Deleting a service removes it and its history.

Component groups

Group related services into clusters (for example "API", "Web", "Infrastructure") so the status page is easier to scan.

• Manage groups in the Groups card at the bottom of the Services page: add a group, rename it, set its sort order, or delete it.
• Assign a service to a group with the Group dropdown on the service form.
• On the public status page, services appear under their group heading, and each group shows a rolled-up status (the worst status among its services). Services with no group render on their own.
• Deleting a group keeps its services — they simply become ungrouped.

Next: Notifications.