A Meta Conversions API queue should preserve the original event_time and event_id across retries, but not every old event remains eligible or useful to replay. Without an age policy, outages create a backlog that wastes requests, distorts diagnostics, and risks sending events without the original consent context.
Use this for WordPress lead forms, WooCommerce purchases, server-side tracking plugins, custom workers, webhook queues, and agencies responsible for browser and server event reconciliation.
Quick answer
Meta CAPI Queue Age Discard and Replay Policy should be handled with a narrow evidence-first workflow: persist source context, classify errors, set age thresholds, then verify the result before making broader changes.
What to check first
- Store original event_time, event_id, event_name, source URL, consent snapshot, enqueue time, attempt count, and last error separately.
- Classify transport, rate-limit, authentication, schema, consent, and age failures into retry, repair, or permanent-close paths.
- Set warning and discard thresholds that respect current Meta requirements and the business value of each event type.
- Preserve event_time and event_id during replay and never manufacture a fresh conversion time to bypass age validation.
- Reconcile replayed server events with browser events and monitor queue age, success, duplicate, discard, and consent rates.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Persist source context | Store original event_time, event_id, event_name, source URL, consent snapshot, enqueue time, attempt count, and last error separately. | Temporary failures retry with bounded backoff and the original event context. |
| Classify errors | Classify transport, rate-limit, authentication, schema, consent, and age failures into retry, repair, or permanent-close paths. | Permanent age, consent, and schema failures leave the active queue with a recorded reason. |
| Set age thresholds | Set warning and discard thresholds that respect current Meta requirements and the business value of each event type. | Replayed browser and server events deduplicate under the same event name and event ID. |
| Keep time and ID immutable | Preserve event_time and event_id during replay and never manufacture a fresh conversion time to bypass age validation. | Operators can report queue age and close reasons without exposing customer data. |
Why this usually happens
- A generic retry worker treats permanent data failures like temporary network errors.
- Some integrations overwrite event_time on every attempt.
- Consent state can change after the original event and must not be inferred at replay time.
- A new event_id can turn one business event into duplicate browser and server conversions.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
queue_policy:
retry: [timeout, connection_reset, rate_limit]
repair: [invalid_parameter, missing_identifier]
close: [consent_denied, outside_accepted_age]
immutable: [event_id, event_time, event_name, consent_snapshot]
metrics: [queue_age, retries, accepted, duplicate, closed]
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Persist source context
- Classify errors
- Set age thresholds
- Keep time and ID immutable
- Reconcile outcomes
What to tell the client or owner
Provide redacted event ID, name, original event time, enqueue time, age, consent snapshot label, attempt count, last error, policy action, and reconciliation result.
Production verification checklist
- Temporary failures retry with bounded backoff and the original event context.
- Permanent age, consent, and schema failures leave the active queue with a recorded reason.
- Replayed browser and server events deduplicate under the same event name and event ID.
- Operators can report queue age and close reasons without exposing customer data.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit a Meta CAPI event queue.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references