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

# Is each package on pace?

> What a package's pacing_index means, where it comes from, and when Apostra tells you a package is behind.

A media buy can sit `active` for weeks while a package delivers a few percent of
its budget. A package's `pacing_index` says whether it is on track, and Apostra
now tells you when a live package falls well behind.

## Read it

The seller reports `pacing_index`. It is AdCP's `pacing_index`, and Apostra
returns the seller's value as it came, on the package's `delivery`.

| `pacing_index` | Meaning |
| - | - |
| `1.0` | On track against the package's plan. |
| Under `1.0` | Behind. `0.5` is half the pace the plan calls for. |
| Over `1.0` | Ahead of plan. |

The value is the seller's own measure, so how it is worked out depends on the
seller. A package whose seller sends none has no `pacing_index`. Apostra does not
publish a number of its own in its place.

## When Apostra tells you a package is behind

> [!NOTE]
>
> The behind-pace notification is in beta and is switched on per organization.
> Ask your Apostra contact to turn it on for your organization.

Apostra checks every live package on every media buy status sweep (hourly). For
an organization in the beta, it notifies the buying account when a package:

* is on an `ACTIVE` media buy and is neither paused nor canceled;
* is inside its own flight, with at least 10% of the flight elapsed when the
  seller's totals were last stored; and
* is below a pace of `0.8`.

The pace is the seller's `pacing_index` when the seller sent one. When it sent
none, Apostra estimates the pace from the package's budget spread evenly over its
own flight and the spend delivered so far. The estimate only decides whether to
tell you. It is never shown as a `pacing_index`, and it is withheld when the
package has no budget, when less than 5% of its flight has elapsed, or when the
budget and the seller's delivery report are in different currencies.

A package whose flight has not opened is never behind, whatever its seller
reports. A flighted buy carries one date-bounded package per window, so each
window is judged inside its own flight.

The notice arrives as a `campaign.unhealthy` notification with
`reason: "package_behind_pace"`. Its data carries the media buy, the package,
`pacingIndex`, `pacingIndexBasis` (`seller` or `estimate`), `flightElapsed`, and
the delivered spend and budget when the package has one. Who is emailed or sees
it in the inbox follows the account's existing notification preferences for
`campaign.unhealthy`, and webhook subscriptions to that event receive it.

A package is told about once per week of its flight. A package that stays
behind is told about again each week. A one-week package gets one notice. Every
notice is stored as a notification on your account, so the record of what you
were told and when stays in Apostra.

The `0.8` threshold and the 10% minimum match the point where the embedded sales
agent starts diagnosing why a package is behind, so you and the seller's agent
agree on which packages are.

## Why a package is behind

Today the notice says the package is behind pace. When a seller reports why
through AdCP indicators on the package, such as `pacing_risk` or
`inventory_shortfall_forecast`, that is the reason to read. Apostra does not yet
request or keep those indicators, so the notice does not name a reason. To see
how a buy that has drifted from its booking is reported, read
[Does your buy still match the booking?](https://docs.apostra.com/v3/booking-answer.md). To change a live buy
whose package is behind, read
[Change a live media buy](https://docs.apostra.com/v3/change-a-live-media-buy.md).


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