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

# Schedule coverage policies

> Check that your schedules have someone on call around the clock, and catch gaps before they turn into a missed page.

A schedule coverage policy checks that your [schedules](/on-call/building-schedules) have someone on call around the clock (24/7). It looks ahead over the next 60 days and flags any window where no active responder is covering the schedule, so gaps get spotted and filled before they turn into a missed page.

Gaps can appear for all sorts of reasons: a rotation that ends without a replacement, working hours that don't add up to full coverage, or a responder being deactivated (or losing their on-call seat) while they were still on an upcoming shift.

<Info>Schedule coverage policies are a [policy](/admin/policies) type, available on Pro and Enterprise plans.</Info>

## Creating a coverage policy

Create a coverage policy from [Settings → Policies](https://app.incident.io/~/settings/policies), the same place you manage every other [policy](/admin/policies). As with other policies, you choose who's notified and on what cadence, and outstanding gaps appear in the policy's **Outstanding** tab, on team **Tasks** pages, and in [policy reports](/admin/policies#policy-reports).

## Choosing which schedules to cover

When you create a coverage policy, you decide which schedules it applies to. You can select schedules directly, or add conditions that match on their [catalog](/catalog/overview) attributes, including the **teams** that own each schedule. This lets a policy target "every schedule owned by the Platform team" and automatically pick up new schedules as they're created.

## Evaluating at the schedule or rotation level

A coverage policy can be evaluated at one of two levels:

* **Schedule**: coverage is checked across the schedule as a whole. As long as *some* rotation has an active responder at every moment, the schedule is covered.
* **Rotation**: coverage is checked for each rotation independently. Every rotation on the schedule must be covered around the clock in its own right.

Rotation-level evaluation is useful when you rely on specific rotations directly. For example, when an [escalation path](/on-call/escalation-paths) points at a single rotation rather than the whole schedule, you need each one to hold its own coverage.

<Info>
  Conditions match schedules, not individual rotations. A rotation-level policy therefore requires *every* rotation on a
  matching schedule to be covered.
</Info>

## Who gets notified

As with other policies, you choose who's responsible for resolving a coverage gap. You can assign one or more people, such as everyone responsible for a schedule, and each assignee is reminded on the cadence you configure.

### When reminders are sent

Because a coverage gap is a window of time in the future, you can anchor each reminder to one of two moments:

* **When the gap is identified** — remind immediately, or a set number of days after the gap is first detected. Good for nudging someone to fill a gap as soon as it appears, even if it's weeks away.
* **When the gap starts** — remind a set number of days before the gap starts, when it starts, or a set number of days after.

You can add several reminders across both anchors, up to 31 days out.

## Surfacing and dismissing gaps

Coverage gaps show up in two places:

* **On the policy**, in the **Outstanding** tab of the policy's side panel.
* **On the schedule**, where gaps are surfaced with a "needs cover" banner you can cycle through to jump straight to each one.

Sometimes a gap is expected and doesn't need filling. You can dismiss a coverage gap with a reason from either place. Dismissing a gap requires the **Dismiss policy violations** permission, and dismissed gaps stay dismissed across future evaluations.