> For the complete documentation index, see [llms.txt](https://docs.podigee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podigee.com/documentation/grow-and-monetize/monetization/protect-playback-during-an-incident.md).

# Protect playback during an incident

Protect listener and viewer playback during an advertising incident, pause paid decisions, use safe fallback, restore delivery, and close the incident with evidence.

Use this guide when an ad, Campaign, Creative, provider, delivery route, or evidence problem can affect new listener or viewer requests. The goal is to stop unsafe or incorrect paid decisions while keeping the podcast or video playable.

## Confirm that an incident needs protection

Open **Monetization > Operations** and inspect the issue. Confirm:

* affected workspace, show, Campaign, Flight, or delivery surface;
* first observed time and current scope;
* whether the problem is unsafe media, wrong targeting, wrong version, no-fill, provider failure, or missing evidence;
* whether clean fallback is available;
* whether current playback is already in progress.

![The current One Podigee Operations control room shows active delivery assurance work, incidents, delayed evidence, and the next action.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-6db53133b0902c0ebe2d348da5710f6f8cfe7c7b%2Fdoc-monetization-067-operations.png?alt=media)

*Start from the incident scope and the displayed next action.*

Do not pause every Campaign when one Flight or one provider is affected. Use the smallest scope that protects listeners and viewers.

## Diagnose the immediate risk

Use the exact decision and playback evidence when possible. Check:

1. whether the selected Creative is safe and authorized;
2. whether the correct Campaign and Flight are serving;
3. whether RSS, HLS, Apple, Spotify, or an external provider is affected;
4. whether a no-fill or clean fallback works;
5. whether analytics and commercial evidence remain linked;
6. whether the issue can create duplicate delivery or money evidence.

If the issue is not clear, treat unsafe media, wrong content, and mixed playback as high risk and protect the smallest affected scope before further investigation.

## Pause new paid decisions

Use **Pause new ad decisions** from the Campaign's **Launch readiness** page when new paid decisions must stop but clean content must remain available.

1. Open **Monetization > Campaigns**.
2. Select the affected Campaign or Flight.
3. Open **Launch readiness**.
4. Find **Live delivery controls**.
5. Confirm the current active state and affected scope.
6. Select **Pause new ad decisions**.
7. Choose the incident reason and effective time.
8. Read the effect on new requests and existing playback.
9. Confirm the action.

![The current One Podigee pause confirmation explains that new paid decisions stop while playback already in progress remains safe.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-890f96ed19670130b32e51c8d17be820f5a5119d%2Fdoc-monetization-061-pause-confirmation.png?alt=media)

*A pause protects new requests without breaking a presentation already in progress.*

Wait until the confirmed state shows **Paused**. A queued pause is not yet a confirmed protection boundary.

## Confirm clean fallback

After the pause, test one new request on the affected surface. Confirm that:

* the episode or presentation still plays;
* no unsafe or wrong paid ad is inserted;
* the configured clean or house fallback is used;
* the request has a recorded decision;
* no paid delivery or revenue evidence is created for a clean fallback.

For a partial-fill break, confirm that the configured slot and duration rules remain intact. Do not replace a safe fallback with an unverified Creative to improve fill during an incident.

## Keep existing playback safe

The pause affects new paid decisions. A listener or viewer who already received a Playback Plan continues within its assigned boundary. Do not invalidate the source media or change the episode identity during the incident unless the content itself is unsafe.

If the problem affects a currently active presentation, use the controlled delivery recovery action and follow the Operations guidance. Do not force a new ad into an existing session.

## Investigate and repair the cause

Use the issue's next action. Common repairs are:

| Cause                    | Repair                                                                       |
| ------------------------ | ---------------------------------------------------------------------------- |
| Wrong Creative           | Quarantine or replace the Creative, then run current checks.                 |
| Missing rights           | Correct the right and create a current Creative version.                     |
| Wrong Campaign or Flight | Correct targeting, priority, or schedule and retest.                         |
| Provider failure         | Suspend the provider or use the next source and inspect the redacted result. |
| Stale release or binding | Rebuild and verify the exact delivery version.                               |
| Analytics or money lag   | Wait for the processing boundary, then reconcile evidence.                   |
| HLS or RSS media problem | Repair the source or delivery binding and verify playback.                   |

Keep the paused state while the repair is unverified. Preserve the incident evidence and original decision records.

## Restore paid delivery

Restore only after the cause is corrected and the exact Campaign setup passes its checks.

1. Confirm the Creative, rights, Inventory, breaks, destination, and fallback are ready.
2. Run the exact Campaign and delivery checks.
3. Test one representative RSS or HLS request.
4. Confirm the decision and playback result.
5. Open **Launch readiness**.
6. Select **Resume delivery**.
7. Confirm the reason and effective time.
8. Wait for the confirmed **Active** state.
9. Test one new request after activation.

![The current One Podigee Launch readiness page shows a Paused delivery state with controls to resume or permanently revoke the Campaign.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-5e8aacb2db51e95c321d566c032b0a879774ef3c%2Fdoc-monetization-061-live-delivery-paused.png?alt=media)

*Resume only after the cause and exact Campaign setup are ready.*

Do not resume only because the provider endpoint responds or a form submits successfully. The delivery system must confirm the active state.

## Use rollback when the active release is wrong

If the incident began after a new setup became active and the previous setup is healthy, choose **Roll back to last healthy release** instead of resuming the same setup. Check the rollback confirmation and its scope. A rollback does not erase the failed release or its incident evidence.

## Close the incident

When delivery is stable:

* confirm the affected scope and duration;
* confirm pause, fallback, repair, and restoration states;
* link the decision, playback, analytics, provider, and money evidence;
* record any affected buyer or publisher promise;
* record the prevention action, such as a new check, policy, or provider version;
* mark the Operations issue closed.

Do not close the incident while qualified evidence or provider receipts are still missing. Use the late-evidence and reconciliation workflows when processing continues after playback is restored.

## Expected result

New listener and viewer requests remain playable during the incident. Unsafe or incorrect paid decisions stop at the smallest affected scope, clean fallback is verified, delivery is restored only after checks pass, and the complete incident evidence remains available for reconciliation and follow-up.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.podigee.com/documentation/grow-and-monetize/monetization/protect-playback-during-an-incident.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.