Delivery health and retries
Server attempt outcomes cover the last seven days, including retries, refunds and test events. Expand the latest failed attempt for its recorded error. Endpoint receipt, conversion capture and destination reporting are separate evidence; retries depend on the failure and available worker attempts.
On this page
The settings panel summarizes recorded server attempts. It does not measure unique orders, browser delivery or downstream attribution. Setup progress separately uses a non-test primary conversion record and never treats the attempt percentage as proof that a destination is fully verified.
What it shows
- Per-destination server attempt percentages over the last seven days.
- The attempt history includes retries, refunds and synthetic test events; it is not a unique-conversion count.
- The latest failed attempt and its recorded error, when available. Use the actual error and timestamp rather than inferring a cause from the color.
Automatic retries
Eligible transient server failures have bounded retry attempts with backoff. Recovery requires a running worker, remaining attempts and a retryable error. Credentials or payload errors may require a correction first. No fixed recovery time is guaranteed, and a synchronous dashboard test failure does not promise a queued retry.
When to step in
- Authentication errors
- Read the provider error, then check the indicated credential, permissions and destination. Reconnect or rotate credentials when the error supports that action.
- Persistent rate limits
- Suggest volume beyond the destination's allowance. Check your account limits at that platform.
- Rejected payloads
- Inspect the rejected field or destination in the provider response. Correct that specific payload or configuration problem before retrying.
Recorded events and destination delivery are separate
A rejected destination delivery does not remove an event already stored in AdProtektor. Records remain subject to retention and deletion policies; this does not recover events the installation never captured.
Recovery after a failure
Keep the website, event ID, failure time and provider response when contacting support. A replay must first account for prior endpoint receipts, destination changes, remaining provider time limits and deduplication behavior. Dashboard test-fire creates a separate sample; it does not replay the original conversion.
Frequently asked questions
How will I know if delivery is failing?
Check server attempt outcomes and expand the latest failure. Then inspect a recent event in the currently configured destination. Historical successes can belong to an older configuration and do not verify a new pixel or property.
Do retries risk duplicate conversions?
Stable event IDs and local dispatch guards reduce repeat sends, but a receipt can be lost after a provider accepts an event. Deduplication depends on the provider, event type and matching fields. Verify destination behavior before replaying; an event ID alone is not a universal guarantee.