> 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-stale-delivery-or-event-processing.md).

# Recover stale delivery or event processing

Recover stale delivery or event processing, replay the safe boundary, and prevent duplicate analytics or money evidence.

Use this guide when a delivery job, audience event, provider receipt, or qualified value stays pending longer than the displayed processing boundary. The correct repair is a controlled replay of the missing step. Do not create a manual event or a second Campaign to make a report move.

## Identify the stale work

Open **Monetization > Operations** and inspect the affected delivery or evidence job. Record the short job reference, Campaign, Flight, episode, delivery method, current state, last progress time, and next retry time.

Common states are:

| State                    | Meaning                                                                 | Operator action                                               |
| ------------------------ | ----------------------------------------------------------------------- | ------------------------------------------------------------- |
| **Queued**               | The work has not started.                                               | Wait until the queue boundary or use the shown retry control. |
| **Running**              | The worker is processing the exact job.                                 | Do not start a second job.                                    |
| **Waiting for evidence** | A listener, viewer, provider, or destination receipt is still expected. | Check the required source and wait for its boundary.          |
| **Retryable failure**    | A temporary dependency failed.                                          | Repair the dependency, then retry once.                       |
| **Stale**                | No progress was recorded within the job boundary.                       | Use the controlled recovery action.                           |
| **Completed**            | The job has durable evidence.                                           | Check the resulting record instead of replaying it.           |
| **Terminal failure**     | The job cannot complete without a new input.                            | Correct the named input and create the next version.          |

![The current One Podigee Operations page shows a delivery assurance issue with a named stale or delayed process and a clear next action.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-f7b6f811b54f142e009fe8e87a79c69ff1cb765a%2Fdoc-monetization-067-issue-detected.png?alt=media)

*Start from the named problem and its next action.*

## Check whether the event is really missing

Before you replay, search **Evidence & Money** for the decision, event, receipt, or qualified delivery. Use the exact Campaign, Creative, episode, request time, and delivery method.

An event can be present but not yet joined to the report. A report can also be behind the event ledger. Do not treat a missing chart point as a missing source event.

Check these records separately:

* audience analytics event;
* ad decision and Playback Plan;
* delivery observation or provider receipt;
* qualification result;
* report or finance projection.

## Use the controlled recovery action

When Operations offers **Retry**, **Recover**, or **Replay evidence**:

1. Open the job detail.
2. Confirm the exact subject and source version.
3. Read the replay boundary and duplicate-protection notice.
4. Select the displayed recovery action once.
5. Wait for the new state.
6. Open the resulting event or evidence record.

![The current One Podigee Operations recovery form shows the exact job, the selected recovery action, the replay boundary, and duplicate protection before submission.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-a9f80eb5fedcde86fd0a404472823fb142391397%2Fdoc-monetization-067-diagnosis-form.png?alt=media)

*A replay must name the exact job and its safe boundary.*

The recovery action should use the original request, decision, presentation, and measurement identity. It must not create a new ad decision or a new commercial identity.

## Understand duplicate protection

One source event can be delivered more than once by a player, provider, or retrying worker. Podigee uses the event or evidence identity to record the source once and mark later attempts as duplicate or already processed.

After replay, confirm:

* the original event remains visible;
* the replay has one job result;
* no second ad decision was created;
* no second qualified delivery or revenue value was created;
* the report or finance projection can now join the existing evidence.

Do not deduplicate by timestamp alone. Use the short event, decision, or evidence reference shown by the job.

## Repair a missing dependency first

If recovery is blocked, follow the named dependency:

| Dependency  | Check                                                            |
| ----------- | ---------------------------------------------------------------- |
| Delivery    | Current show, episode, break, media version, and delivery state. |
| Analytics   | Audience pipeline health and event acceptance.                   |
| Provider    | Connection state, receipt, response, and retry boundary.         |
| Measurement | Creative, qualification rule, and required observation.          |
| Report      | Period, time zone, metric definition, and refresh time.          |
| Finance     | Settlement state and late-evidence handling.                     |

Correct the dependency, then retry the original job. Do not bypass a missing source event with a manual delivery record.

## Wait for late evidence

Some events arrive after playback. A player can stop at the ad, a provider can send a receipt later, or a report can update after the event ledger.

Use the displayed measurement window and processing boundary. If the event arrives after a period is prepared, use the late-evidence workflow. Keep the earlier period unchanged and carry the event to the next period or use a controlled correction when required.

## Check the result in the job detail

Open the completed job and confirm:

* source and destination references;
* exact Campaign, Flight, Creative, episode, and delivery method;
* input and output event identities;
* replay count and deduplication result;
* processing timestamps;
* qualified delivery and revenue result;
* any remaining warning.

![The current One Podigee revenue job detail shows the selected job, its current state, delivery scope, and the evidence result.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-ef87d1b1ad7097633ced378a24cd98551cc57cf8%2Fdoc-monetization-068-job-detail.png?alt=media)

*Use the job detail to prove that the replay completed the intended step.*

Then open the exact ad decision or event. Confirm that the decision and evidence use the same request boundary.

![The current One Podigee Ad decision details page connects the selected Campaign and Creative to the podcast, episode, ad break, privacy mode, qualified value, and exact delivery references.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-a6a46bc4f1c8230e01ac95b529b06c49a9b3d5f9%2Fdoc-monetization-064-decision-evidence.png?alt=media)

*The decision and evidence must describe the same delivery.*

## If the job fails again

Stop after one controlled retry. Escalate when:

* the same job remains stale after the dependency is healthy;
* the replay creates conflicting evidence;
* a completed event has no matching delivery or analytics record;
* a second qualified value appears for one evidence identity;
* the job subject or active delivery version is unclear.

Include the short job and event references, visible state, last progress time, retry result, and affected Campaign or episode. Do not include listener identity or provider secrets.

## Expected result

The stale process either completes from the original evidence boundary or remains safely blocked with a named cause. A controlled replay can converge delivery, analytics, and money evidence without creating a second decision, delivery, or billing result.


---

# 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-stale-delivery-or-event-processing.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.