Skip to main content
HTTP and TCP monitors are the foundation of uptime monitoring. An HTTP monitor sends a request to a URL on a regular interval and records whether the endpoint responded successfully. A TCP monitor opens a raw socket connection to a host and port, making it useful for non-HTTP services like databases, message queues, or custom application servers.

​
HTTP monitors

An HTTP monitor checks that a URL returns a successful response. Overwatch considers any response a sign that the endpoint is reachable — it does not currently match on specific status codes. The monitor tracks latency on every check and computes uptime over a rolling 90-day window.

​
Config fields

​
string
required
The full URL to check, including scheme. For example, https://api.example.com/health.
​
number
required
How often to run the check, in seconds. Minimum is 300 seconds (5 minutes) on Starter, 60 seconds (1 minute) on Pro.

​
Status values

​
Create an HTTP monitor

​
TCP monitors

A TCP monitor attempts to establish a TCP connection to a host and port. If the connection succeeds, the monitor is up. If it times out or is refused, the monitor goes down. TCP monitors apply the same degraded-latency logic as HTTP monitors.

​
Config fields

​
string
required
The hostname or IP address to connect to. For example, db.example.com.
​
number
required
The TCP port to connect to. For example, 5432 for PostgreSQL.
​
number
required
How often to run the check, in seconds.

​
Status values

TCP monitors share the same status set as HTTP monitors: up, degraded, and down.

​
Create a TCP monitor

​
The degraded status

The degraded status applies only when a check succeeds — the endpoint is reachable, but response time is abnormally high. Overwatch compares each check’s latency against a 30-day moving average for that monitor. A significant deviation triggers the degraded status. degraded is distinct from down and is tracked separately in the status history. This lets you distinguish between outright failures and performance regressions without generating false-positive down alerts.
Alert channels can be configured to fire on degraded separately from down. Use this to send a warning-level notification before a performance issue escalates.

​
Updating a monitor

Use PATCH /api/v1/monitors/:id to update a monitor’s name, config, or enabled state. You only need to include the fields you want to change.
When updating config, you must include all config fields for the monitor type — not just the one you’re changing. A partial config will overwrite the stored value.

​
Pausing all monitors

To pause every monitor in your organization at once — for example, during a planned maintenance window — send a POST to the pause-all endpoint:
Re-enable monitors individually using PATCH /api/v1/monitors/:id with "enabled": true, or resume them from the dashboard.

​
Getting check results

Retrieve the history of individual check results for a monitor:
Results are returned in reverse chronological order (most recent first). The default page size is 50, and the maximum is 200. Use the limit query parameter to control page size and cursor to paginate through older results.
Each result includes the check status, latency in milliseconds, and a timestamp.