> ## Documentation Index
> Fetch the complete documentation index at: https://docs.overwatchapp.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Configure HTTP and TCP uptime monitors in Overwatch
> Set up HTTP and TCP monitors to check endpoint reachability and port connectivity. Learn up, down, and degraded statuses and latency thresholds.
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
The full URL to check, including scheme. For example, `https://api.example.com/health`.
How often to run the check, in seconds. Minimum is 300 seconds (5 minutes) on Starter, 60 seconds (1 minute) on Pro.
### Status values
| Status | Meaning |
| ---------- | ------------------------------------------------------------------------------------- |
| `up` | The endpoint responded within normal latency. |
| `degraded` | The endpoint responded, but latency is significantly above the 30-day moving average. |
| `down` | The endpoint did not respond or returned an error. |
### Create an HTTP monitor
```bash theme={null}
curl -X POST https://overwatchapp.dev/api/v1/monitors \
-H "Authorization: Bearer ow_live_sk_" \
-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
The hostname or IP address to connect to. For example, `db.example.com`.
The TCP port to connect to. For example, `5432` for PostgreSQL.
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
```bash theme={null}
curl -X POST https://overwatchapp.dev/api/v1/monitors \
-H "Authorization: Bearer ow_live_sk_" \
-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.
```bash theme={null}
curl -X PATCH https://overwatchapp.dev/api/v1/monitors/ \
-H "Authorization: Bearer ow_live_sk_" \
-H "Content-Type: application/json" \
-d '{
"config": {
"url": "https://api.example.com/health",
"interval": 30
}
}'
```
```bash theme={null}
curl -X PATCH https://overwatchapp.dev/api/v1/monitors/ \
-H "Authorization: Bearer ow_live_sk_" \
-H "Content-Type: application/json" \
-d '{
"enabled": false
}'
```
```bash theme={null}
curl -X PATCH https://overwatchapp.dev/api/v1/monitors/ \
-H "Authorization: Bearer ow_live_sk_" \
-H "Content-Type: application/json" \
-d '{
"enabled": true
}'
```
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:
```bash theme={null}
curl -X POST https://overwatchapp.dev/api/v1/monitors/pause-all \
-H "Authorization: Bearer ow_live_sk_"
```
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:
```bash theme={null}
curl "https://overwatchapp.dev/api/v1/monitors//results" \
-H "Authorization: Bearer ow_live_sk_"
```
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.
```bash theme={null}
# Fetch up to 100 results
curl "https://overwatchapp.dev/api/v1/monitors//results?limit=100" \
-H "Authorization: Bearer ow_live_sk_"
# Fetch the next page using the cursor from the previous response
curl "https://overwatchapp.dev/api/v1/monitors//results?cursor=" \
-H "Authorization: Bearer ow_live_sk_"
```
Each result includes the check status, latency in milliseconds, and a timestamp.