# Uptime monitoring

EvoHub Uptime checks your services on a schedule and tells you when one stops answering, answers wrongly or slows down. This page covers the monitor types, how to create a monitor, and the settings that decide when a monitor counts as down.

## How it works

A monitor checks one target at a fixed interval. When a check fails, the monitor goes **Down**, EvoHub opens an uptime incident, and it alerts you through the monitor's [notification channels](https://docs-dev.evohub.io/uptime-alerts-and-silence-windows.md) and, if you choose, pages your team through On-Call. When a later check passes, the incident closes and EvoHub sends a recovery message.

Monitors live under **Uptime** in the EvoHub console. If you pick a team in the team switcher, the **Monitors** list shows that team's monitors, and new monitors belong to that team.

## Monitor types

| Type | Console label | What it checks | Target |
|------|---------------|----------------|--------|
| HTTP | **HTTP** | Requests a URL and checks the response code, and optionally the response body, headers and SSL certificate. | A full URL, such as `https://example.com/health` |
| Keyword | **Keyword** | Requests a URL and checks that the response body contains a word or phrase. | A full URL |
| TCP | **TCP** | Opens a TCP connection to a port. | `host:port`, such as `db.example.com:5432` |
| Ping | **ICMP (Ping)** | Sends a ping to a host. | A host name or IP address |
| Heartbeat | **Heartbeat (cron / job)** | Waits for your job to ping EvoHub, and alerts when a ping is late. | None. EvoHub gives you a URL to call. |

Heartbeat monitors work the other way round from the rest. See [Heartbeat monitors](https://docs-dev.evohub.io/heartbeat-monitors.md).

## Create a monitor

:::steps
### Open Uptime
In the EvoHub console, open **Uptime** and click **New Monitor**.

### Name it and pick a type
Enter a **Name** and choose the **Monitor Type**. The fields below change to match the type.

### Enter the target
Fill in **URL**, **Host and port** or **Host**, depending on the type.

### Set the schedule
Choose a **Check Interval** and a **Timeout**.

### Set the options you need
Open the sections below the form to add HTTP settings, SSL monitoring, assertions, performance and SLA settings, tags, and alerting. All of them are optional.

### Create
Click **Create Monitor**. EvoHub opens the monitor's page and starts checking.
:::

## Check interval and timeout

| Setting | Options | Default |
|---------|---------|---------|
| **Check Interval** | 15 seconds, 30 seconds, 1 minute, 5 minutes, 15 minutes, 30 minutes, 60 minutes | 5 minutes |
| **Timeout** | 10 seconds, 30 seconds, 60 seconds | 30 seconds |

A check that gets no answer within the timeout fails. A monitor goes down on its first failed check, so you hear about an outage on the next check after it starts.

EvoHub does not currently let you choose the regions checks run from. Each check's location is shown in the monitor's **Recent Checks** table.

## HTTP and keyword options

**Expected Status Code** (HTTP monitors, default `200`): the response code that counts as up.

**Keyword** (keyword monitors): the text the response body must contain. The match is case-sensitive.

**HTTP Settings** (HTTP monitors):

- **Method**: `GET`, `POST`, `HEAD` or `PUT`.
- **Headers**: request headers to send, for example an API token your health endpoint needs.
- **Request Body**: sent with `POST` and `PUT`.
- **Basic Auth**: a username and password.

## Assertions

HTTP monitors can check more than the status code. Open **Assertions** and click **Add assertion**. Every assertion must pass, or the check fails and the reason is recorded, for example "Expected status 200–299, got 503".

| Assertion | Operators | Example |
|-----------|-----------|---------|
| **Status code** | is one of | `200-299,301` |
| **Body** | contains, does not contain | `ok` |
| **JSON value** | equals, does not equal, contains, exists | field `$.status` equals `up` |
| **Header** | equals, contains | field `Content-Type` contains `application/json` |

- A monitor can have up to 10 assertions.
- JSON paths look like `$.status` or `$.items[0].id`.
- Without a status code assertion, **Expected Status Code** still applies.
- Up to 1 MB of the response body is read.

## Slow responses and SLA

Open **Performance & SLA** on any monitor except a heartbeat:

- **Slow if response takes longer than** (milliseconds, 1 to 60000): a passing check slower than this marks the monitor **Degraded** instead of Up. Leave it empty to turn it off. Degraded counts as up for uptime and SLA.
- **Also page on-call when slow**: raises a lower-priority On-Call alert while the monitor is degraded, and resolves it when the monitor recovers. It needs a slow threshold and an escalation policy under **Alerting**.
- **SLA target**: an uptime percentage such as `99.9`. When 30-day uptime falls below it, the monitor is marked as breaching its SLA.

## SSL certificate expiry

HTTP monitors can watch the site's certificate. Open **SSL Monitoring**, turn on **Monitor SSL certificate**, and pick an **Alert threshold**: 7, 14, 30 (the default) or 60 days.

When the certificate has fewer days left than the threshold, EvoHub sends a warning to the monitor's notification channels, for example "SSL certificate expires in 12 days (threshold: 30 days)". The warning is only sent while the monitor is up. The monitor's page shows the days left, and the **Monitors** list flags certificates with less than 30 days left.

## Tags

Use **Tags** to group monitors, for example by service or environment. Press Enter or a comma to add a tag. The **Monitors** list can be filtered by tag.

## Alerting

Under **Alerting**, pick an **Escalation Policy** to page your team through On-Call when the monitor goes down, and choose **Re-alert while still down**: every 5, 15 (the default), 30 or 60 minutes. See [Uptime alerts and silence windows](https://docs-dev.evohub.io/uptime-alerts-and-silence-windows.md).

## The monitor page

Open a monitor from the list to see:

- its current status, and uptime for the last 24 hours, 7 days, 30 days and 90 days
- days left on the SSL certificate, if monitored
- a **Response Time** chart
- **Recent Checks**: status, location, latency, HTTP code, time and error of each check
- **Incidents**: when each outage started and ended, how long it lasted, and its cause
- **Notification Channels** linked to this monitor

From the header you can **Pause** and **Resume** checking, **Edit** the monitor, or delete it. A paused monitor runs no checks.

Individual check results are kept for 90 days.

### Monitor statuses

| Status | Meaning |
|--------|---------|
| Up | The last check passed. |
| Degraded | Checks pass, but slower than the slow threshold. |
| Down | The last check failed. |
| Unknown | The monitor has not been checked yet, or the last result was inconclusive. |

The list also marks monitors that are **Paused**, or muted by a silence window (**Maintenance**).

## Show a monitor on a status page

A status page component can follow a monitor, so your public page updates on its own when the monitor goes down. See [Components and groups](https://docs-dev.evohub.io/components-and-groups.md#sync-from-monitor).

## Permissions and billing

Creating, editing, pausing and deleting monitors needs `uptime:monitor:write`. Owners, Admins and Members have it; Viewers can see monitors but not change them. See [Roles and permissions](https://docs-dev.evohub.io/roles-and-permissions.md).

Uptime checks are billed by usage. Heartbeat monitors are not metered. See [How billing works](https://docs-dev.evohub.io/how-billing-works.md).

## Related

- [Heartbeat monitors](https://docs-dev.evohub.io/heartbeat-monitors.md)
- [Uptime alerts and silence windows](https://docs-dev.evohub.io/uptime-alerts-and-silence-windows.md)
- [Weekly email summary](https://docs-dev.evohub.io/weekly-summary.md)