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

​
url
string
required
The full URL to check, including scheme. For example, https://api.example.com/health.
​
interval
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

StatusMeaning
upThe endpoint responded within normal latency.
degradedThe endpoint responded, but latency is significantly above the 30-day moving average.
downThe endpoint did not respond or returned an error.

​
Create an HTTP monitor

curl -X POST https://overwatchapp.dev/api/v1/monitors \
  -H "Authorization: Bearer ow_live_sk_<secret>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "API health check",
    "type": "HTTP",
    "config": {
      "url": "https://api.example.com/health",
      "interval": 60
    }
  }'

​
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

​
host
string
required
The hostname or IP address to connect to. For example, db.example.com.
​
port
number
required
The TCP port to connect to. For example, 5432 for PostgreSQL.
​
interval
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

curl -X POST https://overwatchapp.dev/api/v1/monitors \
  -H "Authorization: Bearer ow_live_sk_<secret>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Postgres connectivity",
    "type": "TCP",
    "config": {
      "host": "db.example.com",
      "port": 5432,
      "interval": 60
    }
  }'

​
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. 
curl -X PATCH https://overwatchapp.dev/api/v1/monitors/<id> \
  -H "Authorization: Bearer ow_live_sk_<secret>" \
  -H "Content-Type: application/json" \
  -d '{
    "config": {
      "url": "https://api.example.com/health",
      "interval": 30
    }
  }'
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: 
curl -X POST https://overwatchapp.dev/api/v1/monitors/pause-all \
  -H "Authorization: Bearer ow_live_sk_<secret>"
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: 
curl "https://overwatchapp.dev/api/v1/monitors/<id>/results" \
  -H "Authorization: Bearer ow_live_sk_<secret>"
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. 
# Fetch up to 100 results
curl "https://overwatchapp.dev/api/v1/monitors/<id>/results?limit=100" \
  -H "Authorization: Bearer ow_live_sk_<secret>"

# Fetch the next page using the cursor from the previous response
curl "https://overwatchapp.dev/api/v1/monitors/<id>/results?cursor=<cursor_id>" \
  -H "Authorization: Bearer ow_live_sk_<secret>"
Each result includes the check status, latency in milliseconds, and a timestamp.