# On-Call overview

EvoHub On-Call receives alerts from your monitoring tools and makes sure the right person hears about them. This page explains the building blocks and how an alert travels from your monitoring tool to a person's phone.

## How an alert reaches someone

```mermaid
flowchart LR
  A[Monitoring tool] -->|webhook or email| B[Integration]
  B --> C[Alert]
  C --> D[Escalation policy]
  D -->|step 1, 2, 3…| E[Person or schedule]
  E --> F[Voice call / push / email]
```

1. **An integration receives the alert.** Each integration has its own webhook URL (or, for the email integration, its own inbound address). Your monitoring tool sends to it.
2. **EvoHub opens an alert.** The integration's parser reads the tool's payload and creates an alert with a title, severity, description and labels. If an open alert with the same fingerprint already exists, EvoHub counts a repeat on that alert instead of opening a new one.
3. **The integration's escalation policy starts.** The policy is a list of steps. Each step names a person or a schedule, how long to wait, and optionally how to notify.
4. **A schedule answers "who is on call now".** When a step targets a schedule, EvoHub looks at the schedule's layers, rotations and overrides to find the person on duty at that moment.
5. **The person is notified.** By default EvoHub uses the channels the person turned on for themselves (voice call, mobile push, email). A step can force one channel instead.
6. **Someone responds.** Acknowledging, taking over or resolving the alert stops the escalation. If nobody responds, the next step runs.
7. **The source recovers.** For most integrations, the recovery notification resolves the matching alert automatically.

## The building blocks

| Concept | What it is | Where |
| --- | --- | --- |
| **Integration** | A connection to one monitoring tool, with its own URL and key, attached to an escalation policy. | **On-Call → Integrations** |
| **Alert** | One problem reported by a tool (or created by hand). Has a status: triggered, acknowledged, resolved or suppressed. | **On-Call → Alerts** |
| **Escalation policy** | Who is notified, in what order, after how long, and whether the chain repeats. | **On-Call → Escalation Policies** |
| **Schedule** | Who is on call when. Made of layers; each layer is a rotation of people. | **On-Call → Schedules** |
| **Override** | A temporary replacement on a schedule, for example to cover a vacation. | A schedule's **Overrides** section |
| **Incident** | A human-declared, coordinated response with a timeline, which you can publish to a status page and write a postmortem for. | **On-Call → Incidents** |
| **Maintenance** | A planned window during which On-Call pages nobody. | **On-Call → Maintenance** |

On-Call does not have a separate "service" object. An alert is routed by the integration it arrived through, and that integration's escalation policy decides who is paged.

## Set up On-Call for the first time

:::steps
### Turn on your own notifications
Open **My Account → Notifications**. Turn on **Mobile Push** (sign in to the EvoHub mobile app first), **Phone Call** (verify your phone number in **Settings** first) and **Email**. See [Notifications](https://docs-dev.evohub.io/notifications.md).
### Create a schedule
Go to **On-Call → Schedules → New Schedule**, choose the timezone your team works in, and add a layer with the people who rotate. See [Schedules and rotations](https://docs-dev.evohub.io/schedules-and-rotations.md).
### Create an escalation policy
Go to **On-Call → Escalation Policies → New Policy**. Make step 1 target the schedule, and add a second step for a backup. See [Escalation policies](https://docs-dev.evohub.io/escalation-policies.md).
### Connect a monitoring tool
Go to **On-Call → Integrations → + Add Integration**, pick your tool, select the escalation policy and copy the webhook URL into the tool. See [Integrations overview](https://docs-dev.evohub.io/integrations-overview.md).
### Send a test alert
Trigger a test from your monitoring tool, or create one with **On-Call → Alerts → New Alert** and choose your escalation policy. Check that the right person is notified and can acknowledge it.
:::

> [!TIP]
> Moving from Opsgenie? The built-in importer creates schedules, escalation policies and integrations from your Opsgenie account. See [Migrate from Opsgenie](https://docs-dev.evohub.io/migrate-from-opsgenie.md).

## Who can do what

On-Call follows your organization roles. By default, Owners, Admins and Members can respond to alerts and configure schedules, escalation policies and integrations; Viewers can see everything but change nothing. Custom roles can grant individual On-Call permissions, such as responding to alerts without editing schedules. People who appear in rotations, escalation steps and overrides must hold the permission to respond to alerts. See [Roles and permissions](https://docs-dev.evohub.io/roles-and-permissions.md).

## What counts toward usage

On-Call is billed by usage, not per seat. Each new alert counts as one ingested alert; repeats of an alert that is still open do not. Voice calls are metered as well. See [How billing works](https://docs-dev.evohub.io/how-billing-works.md) for current rates.

## Related

- [Alerts and incidents](https://docs-dev.evohub.io/alerts-and-incidents.md)
- [Escalation policies](https://docs-dev.evohub.io/escalation-policies.md)
- [Integrations overview](https://docs-dev.evohub.io/integrations-overview.md)
- [Mobile app](https://docs-dev.evohub.io/mobile-app.md)