> 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/retry-failed-report-delivery.md).

# Retry failed report delivery

Retry a failed report run or delivery safely, while keeping the original report version, recipient scope, and external receipt.

Use this guide when a scheduled or manual report did not reach its API, warehouse, SFTP, object storage, or approved recipient destination. First separate a report generation problem from a delivery problem. A safe retry repeats the same completed report with the same request identity. It does not create a new report definition or change Campaign data.

## Find the failed run

Open **Monetization > Evidence & Money > Saved reports**. Select the report, then open **Delivery history** or **Operations**.

![The current One Podigee Evidence & Money view shows this month's qualified delivery, fill rate, qualified revenue, no-fill decisions, a daily chart, and the media and money breakdown.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-ab157f76d1c3f5f7be3a2d369de4c2995b42dd3b%2Fdoc-monetization-072-reports-overview.png?alt=media)

*Use Evidence & Money to find the report run and its delivery state.*

Record:

* report name and exact report version;
* reporting period and time zone;
* output format and schema profile;
* destination and recipient scope;
* run state and delivery attempt number;
* failure reason, request digest, and external receipt when available.

Do not use the most recent report row without checking its version and period.

## Separate generation from delivery

| State                  | Meaning                                                       | Correct action                                                                |
| ---------------------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| **Report failed**      | Podigee could not create the report artifact.                 | Fix scope, metric, data, or processing problem, then create the required run. |
| **Report ready**       | The artifact exists and is immutable.                         | Inspect the artifact and retry its delivery when the attempt failed.          |
| **Delivery retryable** | The destination or network returned a temporary failure.      | Repair the destination and retry the same attempt.                            |
| **Delivery terminal**  | The destination rejected the report or the retry limit ended. | Correct the destination or create a new binding version.                      |
| **Delivered**          | The destination accepted the report and returned a receipt.   | Do not retry unless the destination owner requests a controlled resend.       |

An unavailable API, object store, SFTP route, or warehouse can be a delivery failure even when the report itself is ready.

## Check the destination before retry

Confirm:

* the destination is active;
* the service principal still has access;
* the stored secret is valid;
* the endpoint, bucket, dataset, or SFTP route is correct;
* the file format and schema are accepted;
* the destination owner expects the report;
* the last attempt did not already receive the file.

If the recipient was revoked or the share expired, update the recipient or create a new delivery binding according to the workspace policy. Do not change the historical attempt.

## Retry one failed delivery

When the page offers **Retry delivery**:

1. Open the failed attempt.
2. Confirm the report version, period, destination, and recipient scope.
3. Read the duplicate-protection notice and external receipt state.
4. Repair the named temporary destination problem.
5. Select **Retry delivery** once.
6. Wait for the new attempt to finish.
7. Confirm the new state and receipt.

The retry uses the same report artifact, request key, digest, and delivery binding. If the destination accepted the earlier request but its receipt was lost, the retry returns or records the original receipt instead of sending a second financial meaning.

## Handle common failures

| Failure                                 | Safe repair                                                                              |
| --------------------------------------- | ---------------------------------------------------------------------------------------- |
| API unavailable or timeout              | Check the endpoint and wait for the retry boundary. Retry once when healthy.             |
| Warehouse or object storage unavailable | Check the service account, bucket or dataset, quota, and region.                         |
| SFTP connection failure                 | Check the route, host key, credential, and available space.                              |
| Schema rejected                         | Create a new binding version with the required schema. Do not mutate the old attempt.    |
| Recipient revoked                       | Confirm the new recipient has report access, then create or update the delivery binding. |
| Share expired                           | Create a new time-limited share and record the intended recipient.                       |
| Empty output                            | Check report scope, period, filters, metric permissions, and data freshness.             |
| Duplicate suspected                     | Check request digest and external receipt before any resend.                             |

## Create a new binding only when the destination changed

Create a new report delivery binding when the endpoint, schema, service principal, recipient scope, or data policy changed. Test and activate the new binding before the next scheduled run.

Keep the old binding and failed attempt as evidence. Do not use a new binding to hide an uncertain delivery result from the old binding.

## Check the final receipt

After the retry, confirm:

* the report run is complete;
* the artifact digest matches the original report version;
* the delivery attempt is **Delivered**;
* the external receipt is present or the destination confirms the original receipt;
* the row count and schema match the report definition;
* the failed attempt remains visible in history;
* no Campaign, delivery, or finance record changed because of the report retry.

If the destination accepted the file but Podigee has no receipt, resolve the uncertainty with the destination owner before retrying again.

## Escalate after one controlled retry

Escalate when the same report remains undelivered after the destination is healthy, when the destination and Podigee disagree about receipt, or when a report contains a wrong period, scope, currency, or metric definition. Include the short report, run, binding, attempt, and external receipt references. Do not include report credentials or private recipient data.

## Expected result

The intended report version reaches the approved destination once, with a clear receipt and delivery history. A retry does not create a second report meaning, change Campaign delivery, or duplicate a financial record.


---

# 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/retry-failed-report-delivery.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.