> ## Documentation Index
> Fetch the complete documentation index at: https://docs.uptimeio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Core Concepts

> The building blocks of UptimeIO: monitors, locations, incidents, notifications and status pages

This page explains the ideas you will meet throughout the product and the API. Each section links to the guide that goes deeper.

## Monitors

A monitor is one thing you want to watch: a website, an API, a server, a port, a DNS record or a scheduled job. UptimeIO supports six types.

| Type | Watches | Example target |
| - | - | - |
| [**HTTP**](/monitors/http) | Websites and APIs | `https://api.example.com/health` |
| [**Keyword**](/monitors/keyword) | Page content | Checks that "Welcome" appears on the homepage |
| [**Ping (ICMP)**](/monitors/ping) | Server reachability | `server.example.com` |
| [**Port (TCP)**](/monitors/port) | A service port | SMTP on 25, SSH on 22, MySQL on 3306 |
| [**DNS**](/monitors/dns) | DNS records | Verify `example.com` resolves to the right address |
| [**Heartbeat**](/monitors/heartbeat) | Cron jobs and scheduled tasks | Your backup script pings UptimeIO when it finishes |

Monitors can be organized into **groups**, tagged, paused and resumed.

### Check intervals

The interval is how often a monitor runs. The longest allowed is 24 hours. The shortest depends on your plan:

| Plan | Shortest interval |
| - | - |
| Free | 5 minutes |
| Pro | 1 minute |
| Scale | 1 minute |

See [Plans & Billing](/billing/plans) for monitor limits.

## Probe locations

Checks run from multiple probe locations (see the [full list](/monitors/probe-locations)). Running checks from several places tells you whether a problem is real and whether it affects everyone or only some regions.

* On **Pro and Scale** you choose which locations run regular checks for each monitor (at least one).
* On **Free**, UptimeIO chooses the locations automatically.

Confirmation checks can use locations beyond your selection, so the confirmation rule below always holds.

## Incidents

An incident is a period in which a monitor is failing. UptimeIO is deliberately careful about opening one.

### How an incident opens

<Steps>
  <Step title="A check fails">
    One failed check is not enough to declare an outage.
  </Step>

  <Step title="Retries from other locations">
    The check is repeated from other locations a second apart.
  </Step>

  <Step title="Confirmation">
    An incident opens only when several locations confirm the failure. You are then notified.
  </Step>
</Steps>

### How an incident resolves

Recovery is confirmed the same way, by several locations. This prevents an incident from flapping open and closed on a single lucky check.

### Incident causes

An incident records why it opened:

| Cause | Meaning |
| - | - |
| `timeout` | The check did not complete in time, or a heartbeat did not arrive |
| `connection_error` | The target could not be reached |
| `status_code` | An HTTP response status was not one of the expected codes |
| `keyword_missing` | A keyword check did not match |
| `ssl_error` | The SSL certificate is expired or invalid |
| `dns_error`, `dns_validation_error` | DNS resolution failed or returned unexpected records |
| `slow_response` | Response time exceeded the threshold you set |

**Slow response** incidents use the threshold you configure on the monitor. They resolve once the response time stays below 80% of the threshold for three consecutive checks.

### Incident status

Incidents move through `open`, `acknowledged`, `resolved` and `closed`. Read [Understanding Incidents](/essentials/understanding-incidents) for the full lifecycle.

## SSL and domain expiry

HTTP monitors can also watch the SSL certificate, and HTTP, keyword and DNS monitors can watch the domain's registration.

* **SSL certificate expiry**: warnings are sent to your notification destinations at the thresholds you select from 30, 15, 7 and 1 days before expiry (default: 7 and 1). They do not open an incident. An expired or invalid certificate does open an incident, which resolves automatically once a valid certificate is served.
* **Domain expiry**: the registration expiry date is looked up through RDAP (more often as expiry approaches), expiry is evaluated hourly, and warnings are sent at the thresholds you select from 30, 15, 7 and 1 days before it (default: all four). The domain must be a publicly registered domain name. IP addresses, `localhost` and internal names are rejected. Some country-code domains do not publish expiry dates; for those, UptimeIO reports the date as not published and sends no warnings.

## Notification destinations

A destination is a place alerts are delivered. You add destinations once for your organization, choose which events each one receives, and then assign them to monitors.

| Destination | Needs |
| - | - |
| **Email** | A verified email address |
| **Slack** | Slack authorization |
| **Webhook** | A URL (HTTP or HTTPS) and optional headers |
| **Telegram** | A Telegram chat |
| **Pushover** | Your Pushover user key and API token |

Set destinations up under **Destinations** in the sidebar. See [Notifications](/notifications/overview) and the pages under Integrations.

## Status pages

A status page is a public page that shows the live state of the monitors you choose. Use one to keep customers informed.

<CardGroup cols={2}>
  <Card title="Branding" icon="palette">
    Logo, colors and custom CSS on every plan
  </Card>

  <Card title="Custom domains" icon="globe">
    Serve the page from your own domain, for example `status.yourcompany.com` (Pro and Scale)
  </Card>

  <Card title="Subscribers" icon="envelope">
    Visitors can subscribe to incident updates
  </Card>

  <Card title="Maintenance and announcements" icon="wrench">
    Announce planned maintenance and post updates
  </Card>
</CardGroup>

Free includes 1 status page, Pro 20 and Scale 100. Removing UptimeIO branding (whitelabel) requires Scale. Manage status pages in the dashboard or through the [API](/api-reference/status-pages/create).

## Heartbeat monitoring

Heartbeat monitors work the other way round: instead of UptimeIO checking your service, your job calls UptimeIO.

<Steps>
  <Step title="Create the monitor">
    You choose an expected interval and a grace period. UptimeIO gives you a unique URL such as `https://heartbeat.uptimeio.com/heartbeat/hb_abc123def456`.
  </Step>

  <Step title="Ping it from your job">
    ```bash theme={null}
    curl -fsS https://heartbeat.uptimeio.com/heartbeat/hb_abc123def456
    ```
  </Step>

  <Step title="UptimeIO watches the schedule">
    If no ping arrives within the expected interval plus the grace period, an incident opens. It resolves after three consecutive on-time pings.
  </Step>
</Steps>

The expected interval follows your plan's shortest interval (5 minutes on Free, 1 minute on Pro and Scale). See [Heartbeat monitoring](/monitors/heartbeat) for rate limits and options.

## Data retention

UptimeIO keeps check history for 90 days on Free and 365 days on Pro and Scale. Uptime percentages are calculated from the data in that window. Older check data is removed.

## Teams and projects

Monitors, groups and incidents live in a **project**, and projects live in an **organization**. Free is for a single owner with one project. Pro and Scale allow team members and projects up to fair-use limits of 100 each; there is no per-seat charge. See [Projects](/account/projects) and [Team members and roles](/account/team-and-roles).

## Next steps

<CardGroup cols={2}>
  <Card title="Quick start" icon="rocket" href="/quickstart">
    Create your first monitor
  </Card>

  <Card title="Monitor types" icon="list-check" href="/monitors/http">
    Learn each type in detail
  </Card>

  <Card title="Notifications" icon="bell" href="/notifications/overview">
    Set up alerts
  </Card>

  <Card title="API reference" icon="code" href="/api-reference/introduction">
    Automate with the API
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.