A WordPress or WooCommerce worker can repair clock drift by gradually slewing time or by stepping the system clock. Queue leases, visibility timeouts, retry schedules, token expiry, monotonic timers, and health checks may react differently. If retry code also replaces the original event_time, Meta diagnostics and browser-server deduplication become harder to trust. The remediation needs a canary that tests both clock behavior and conversion evidence.
Use this for Meta CAPI events sent from WordPress cron, Action Scheduler, queue workers, containers, serverless jobs, CRM callbacks, or retry pipelines.
Quick answer
Measure current offset and identify whether the platform slews or steps corrections. Use one synthetic canary worker and immutable event IDs. Queue normal, delayed, future, duplicate, browser-plus-server, lease-expiry, and token-boundary fixtures. Correct time, observe wall clock and monotonic timers, then compare lease ownership, retry schedule, original event_time, request time, Meta diagnostics, and exactly-once business outcomes before expanding the cohort.
What to check first
- Record worker, host, image, NTP source, offset, sync state, correction mode, wall clock, monotonic timer, process start, and timezone.
- Inventory queue lease, visibility timeout, retry schedule, token expiry, event ID, original event_time, request time, and consent state.
- Create slew, forward-step, backward-step, delayed, future, duplicate, browser-plus-server, lease-expiry, and token-boundary fixtures.
- Correct one non-revenue canary and observe claim ownership, timers, retries, payload mutation, diagnostics, and deduplication.
- Define rollout and rollback thresholds for offset, duplicate outcomes, lost leases, queue age, rejection, and token failures.
Why this usually happens
- Wall-clock corrections and monotonic process timers serve different purposes.
- A backward step can make a lease appear younger while a forward step can expire it suddenly.
- Retry code may recalculate event_time from send time and erase the customer-action timestamp.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture,mode,offset_before_ms,offset_after_ms,lease_owner,retry,event_id,event_time_mutated,meta_result
slew-1,slew,4200,18,w-canary,0,lead-771,no,accepted
step-fwd,step,91000,12,w-canary,1,lead-772,no,deduped
step-back,step,-65000,15,w-canary,0,lead-773,no,accepted
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory clocks, correction modes, queue timers, and event fields. | Record worker, host, image, NTP source, offset, sync state, correction mode, wall clock, monotonic timer, process start, and timezone. | All active workers report synchronized clocks inside the approved budget. |
| Choose one synthetic canary with stable event IDs and no revenue impact. | Inventory queue lease, visibility timeout, retry schedule, token expiry, event ID, original event_time, request time, and consent state. | Slew and step fixtures preserve queue ownership or recover safely. |
| Correct time through the approved service while monitoring wall and monotonic timers. | Create slew, forward-step, backward-step, delayed, future, duplicate, browser-plus-server, lease-expiry, and token-boundary fixtures. | Original event_time and event ID survive retries unchanged. |
| Keep original event_time and event ID immutable through retries. | Correct one non-revenue canary and observe claim ownership, timers, retries, payload mutation, diagnostics, and deduplication. | Meta diagnostics and business records show one outcome per fixture. |
Decision rule
Promote the correction when offset remains in budget, no claim is lost or duplicated, retry timing is explainable, original event_time stays immutable, and browser plus server fixtures deduplicate to one outcome.
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 |
|---|
| Small offset | NTP slew | Lease and retry timers stay stable |
| Forward step | Clock jumps ahead | Expired work is handled once |
| Backward step | Clock repeats wall time | No duplicate claim or event |
| Delayed retry | Original event_time retained | Accepted and deduplicated |
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.
- Inventory clocks, correction modes, queue timers, and event fields.
- Choose one synthetic canary with stable event IDs and no revenue impact.
- Correct time through the approved service while monitoring wall and monotonic timers.
- Keep original event_time and event ID immutable through retries.
- Expand by worker cohort only after leases, tokens, diagnostics, and outcomes pass.
Production verification checklist
- All active workers report synchronized clocks inside the approved budget.
- Slew and step fixtures preserve queue ownership or recover safely.
- Original event_time and event ID survive retries unchanged.
- Meta diagnostics and business records show one outcome per fixture.
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.
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.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, roles, data volume, cache, browser behavior, and integrations. Finish with one controlled production fixture when the result depends on the real CDN, email provider, worker clock, crawler response, or browser storage.
What evidence should be retained?
Keep exact versions, stable IDs, UTC timestamps, sanitized requests or logs, 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.
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 worker timing.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Test token expiry during a forward clock step
Extend the queue fixture with the Meta CAPI token-expiry forward-clock test to verify credential rotation, unique leases, immutable event identity, safe retries, and one deduplicated conversion.
Helpful references