Meta Conversions API events created or sent by WordPress workers can be rejected, delayed, or misreported when the host clock drifts. Repairing NTP changes the runtime clock but should not rewrite the original event_time stored with a lead or purchase. Retries must also preserve the event ID used for browser-server deduplication. A small canary proves time correction and event semantics together.
Use this for WordPress and WooCommerce tracking sent by cron, Action Scheduler, queue workers, containers, serverless jobs, CRM callbacks, or retry pipelines.
Quick answer
Measure clock offset on every event-producing and event-sending runtime. Select one non-revenue canary worker, preserve queued payloads, repair its time synchronization, restart only the required service, and send synthetic browser and server fixtures with stable event IDs and original event_time values. Compare host offset, queue age, request time, Meta diagnostics, and deduplication before expanding the rollout.
What to check first
- Inventory web, cron, queue, Action Scheduler, container, database, load balancer, CRM, and serverless clocks.
- Record NTP source, sync state, offset, leap state, timezone, process start, image, worker role, and last heartbeat.
- Inspect queued payloads for original event_time, event ID, creation time, retry count, next attempt, and consent state.
- Create normal, delayed, future, milliseconds, duplicate, browser-plus-server, and stale-by-policy fixtures.
- Define canary health thresholds for offset, rejection, queue lag, deduplication, duplicate business outcomes, and rollback.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Quarantine workers outside the approved clock-offset budget. | Inventory web, cron, queue, Action Scheduler, container, database, load balancer, CRM, and serverless clocks. | All active workers report synchronized clocks inside the approved offset. |
| Repair NTP or host time service on one canary and restart only necessary processes. | Record NTP source, sync state, offset, leap state, timezone, process start, image, worker role, and last heartbeat. | Normal and delayed events retain their original action time. |
| Keep original event_time and event ID immutable through queue retries. | Inspect queued payloads for original event_time, event ID, creation time, retry count, next attempt, and consent state. | Future and millisecond fixtures fail before transmission. |
| Validate seconds, plausible range, consent, queue age, and deduplication before upload. | Create normal, delayed, future, milliseconds, duplicate, browser-plus-server, and stale-by-policy fixtures. | Meta diagnostics and browser-server tests show one deduplicated event per fixture. |
Why this usually happens
- Containers can inherit unsynchronized hosts or start before time service is healthy.
- Retry code may replace event_time with send time and hide the original customer action.
- Different web and worker clocks make a stable event ID appear to represent events at implausibly different times.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
worker,offset_ms,synced,event_id,event_time,request_time,retry,meta_result
canary-a,18,yes,lead-test-901,1786716000,1786716002,0,accepted
canary-a,22,yes,lead-test-902,1786712400,1786716060,2,accepted
worker-b,91000,no,lead-test-903,1786716151,,0,blocked
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Normal lead | Current seconds and stable event ID | Accepted and deduplicated |
| Delayed retry | Original event time with later request | Accepted according to policy |
| Future event | Beyond allowed clock budget | Blocked before upload |
| Milliseconds | 13-digit timestamp | Rejected by local validation |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Quarantine workers outside the approved clock-offset budget.
- Repair NTP or host time service on one canary and restart only necessary processes.
- Keep original event_time and event ID immutable through queue retries.
- Validate seconds, plausible range, consent, queue age, and deduplication before upload.
- Expand by worker cohort while watching Meta diagnostics, rejection, lag, and duplicate outcomes.
Decision rule
Promote the canary only when synchronized offset stays within budget, original event_time survives retries, stable event IDs deduplicate correctly, and no queue, lease, or business effect regresses.
Production verification checklist
- All active workers report synchronized clocks inside the approved offset.
- Normal and delayed events retain their original action time.
- Future and millisecond fixtures fail before transmission.
- Meta diagnostics and browser-server tests show one deduplicated event per fixture.
Field notes
- Do not use live customer purchases as the first canary.
- Keep timezone display separate from Unix timestamp validation.
- Record whether the platform steps or slews the clock because large jumps can affect timers and leases.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, roles, data volume, browser behavior, cache, and integrations. Finish with one controlled production fixture when the result depends on the real CDN, email route, worker clock, crawler response, or browser storage.
What evidence should be retained?
Keep the smallest useful evidence set: exact versions, stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, decision, and final verification. Redact customer data, cookies, secrets, order keys, and full advertising identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, accessibility, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback so the next attempt starts with facts.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a successful request, quiet log, or correct screenshot as proof that the complete user outcome is correct.
- Do not leave debug logs, test records, broad credentials, temporary roles, or browser overrides active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, 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 Meta CAPI event timing.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Test queue leases under slew and step corrections
After repairing one clock, run the Meta CAPI NTP slew versus step queue lease test to verify claim ownership, retry timers, immutable event_time, token expiry, diagnostics, and browser-server deduplication.
Helpful references