> 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/recover-a-failed-serving-activation.md).

# Recover a failed serving activation

Recover a Campaign activation that did not become current, while keeping the last healthy delivery setup in control.

Use this guide when publication or a serving activation does not become **Active**. A failed activation is not a failed Campaign plan. Podigee keeps the last confirmed delivery state in control until a new setup passes its checks and the delivery system confirms it.

## Read the current state

Open **Monetization > Campaigns**, select the Campaign, then open **Launch readiness**. Read **Current delivery state** and **Prepared Campaign setup**.

| State or message            | Meaning                                            | What listeners receive                          |
| --------------------------- | -------------------------------------------------- | ----------------------------------------------- |
| **Publication in progress** | Podigee is checking or activating the exact setup. | The earlier confirmed setup remains in control. |
| **Activation failed**       | The requested setup could not become current.      | The last confirmed setup remains in control.    |
| **Retry scheduled**         | Podigee will try the same activation again.        | The last confirmed setup remains in control.    |
| **Active**                  | The delivery system confirmed the setup.           | Eligible requests can use the active Campaign.  |
| **Paused**                  | Paid decisions are stopped by an operator control. | New requests use the configured clean fallback. |

![The current One Podigee Launch readiness page shows that Campaign publication is in progress while the previous active setup remains available.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-b67fd63f5c184776489b47d79527a3cef0afc38b%2Fdoc-monetization-054-publication-in-progress.png?alt=media)

*A queued activation is not proof that the new setup is live.*

## Do not submit the same activation again

While publication is in progress or a retry is scheduled:

* Do not select the publish action again.
* Do not change the Campaign unless the failure message tells you to correct an input.
* Do not pause or revoke the previous active setup only because the new setup is waiting.
* Do not report delivery from the prepared setup as live delivery.

Wait for the result or open **Monetization > Operations** when the page provides an operator action.

## Find the failed step

Open the activation details and identify the first failed step. Common steps are:

* exact Campaign checks;
* Inventory or capacity confirmation;
* Creative media or rights confirmation;
* ad break or delivery binding;
* destination connection;
* release preparation;
* serving activation acknowledgement;
* post-activation verification.

Use the message as the source for the repair. Do not infer that every failed activation is a provider failure.

## Repair the input when the message names one

If the failed step names a Campaign input:

1. Open the named record.
2. Confirm that the current version is intended.
3. Correct the smallest problem.
4. Save a new version when the record is versioned.
5. Return to Launch readiness.
6. Run the exact Campaign checks again.
7. Complete the review rule shown for the changed setup.
8. Publish the current checked setup.

Examples include an expired Creative right, an unavailable Inventory package, a missing ad break, or a destination setting that no longer matches the Flight.

## Repair a temporary serving or connection problem

If Operations shows a retryable connection, serving, or provider problem:

1. Check whether Podigee has scheduled a retry.
2. Keep the last confirmed state in control.
3. Confirm that the connected destination is healthy.
4. Wait for the retry to finish, or use the displayed retry control once.
5. Confirm the activation result in Launch readiness.

Do not create a second Campaign to work around a temporary activation failure. This can create duplicate delivery or a double commercial promise.

## Use rollback only when the new activation is unhealthy

If the new setup became **Active** and delivery is wrong, use **Roll back to last healthy release** from the live delivery controls. Rollback is not the normal response to a publication that never became active.

If activation failed before the new setup became current, the previous setup is already protected. Correct the cause and publish a new checked setup instead of rolling back a version that did not go live.

![The current One Podigee Launch readiness page shows that publication will retry, the new setup is not live, and the earlier setup remains active.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-2d0d04c73cf2709c71fe333d80410d09f8269113%2Fdoc-monetization-054-safe-publication.png?alt=media)

*The earlier healthy setup remains active when the new activation fails.*

## Confirm the result

After the retry or corrected publication, confirm all of the following:

* **Current delivery state** is **Active** for the intended setup.
* The active version matches the setup that passed the latest checks.
* The failed setup remains visible as history and is not shown as active.
* Operations shows no unresolved activation failure for the Campaign.
* A test request or delivery check uses the active version.
* Analytics and commercial evidence use the same Campaign and delivery version.

![The current One Podigee Launch readiness page shows an Active delivery state with controls to pause new ad decisions, roll back, or revoke the Campaign.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-0f74b77e5b511a108476ac120aa6b75354fe2d85%2Fdoc-monetization-061-live-delivery-active.png?alt=media)

*Only the confirmed active version controls new eligible decisions.*

## When activation keeps failing

Stop after one correct repair and one retry. Escalate when:

* the same exact setup fails at the same step;
* the message names a serving or provider fault that remains healthy on retry;
* the displayed active version and activation receipt disagree;
* the failure could affect an already published Flight, listener playback, or billing evidence;
* no clear next action is shown.

Include the short Campaign reference, prepared setup reference, failed step, visible state, retry result, and time. Copy a full identifier only when support asks for it.

## Expected result

The failed activation is either corrected and confirmed as active, or the last healthy setup stays in control while the issue is escalated. No uncertain or partially activated Campaign can replace the confirmed serving state.


---

# 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/recover-a-failed-serving-activation.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.