A virtual machine, container host, or restored snapshot can step its clock forward after an NTP correction. Meta CAPI workers may then consider an access token, queue lease, retry deadline, cache entry, or event age expired. Events can fail authentication, release duplicate leases, arrive with implausible event_time, or fall outside the useful attribution window even though application code did not change.
Use this for Meta Conversions API implementations, WordPress server-side tracking, queue workers, container platforms, agencies, and observability teams.
Quick answer
Do not change production time to test this. In an isolated environment, freeze one synthetic browser and server event pair with stable event_id. Record wall clock, monotonic clock, NTP offset, token metadata, queue lease, retry deadline, event_time, request time, response, and dedup result. Simulate a bounded forward step through a clock abstraction or test container. Authentication, lease, retry, and event-age decisions should fail safely, emit clear telemetry, rotate credentials through the approved path, and recover without duplicate conversions.
What to check first
- Inventory every wall-clock and monotonic-clock dependency in token, cache, queue, retry, event-time, and deduplication code.
- Create valid-token, near-expiry, expired, rotated, queued, in-flight, retried, duplicate, and delayed-event fixtures.
- Simulate bounded forward steps and NTP slew through an isolated clock provider, never by changing the production host clock.
- Capture token decision, lease owner, retry time, event_time, request, Meta response, event_id, and browser-server deduplication.
- Test credential rotation, worker restart, queue recovery, replay limits, monitoring alerts, and one final business conversion.
Why this usually happens
- Wall-clock time can jump while monotonic duration should not.
- Token, lease, and retry code may use inconsistent clock sources.
- Recovery jobs can rewrite event timestamps or event IDs to make a retry look new.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture,clock_step_s,token_state,lease_state,event_time,retry,event_id,meta_response,dedup,business_result
MC-81,0,valid,owned,14:00,0,evt-81,accepted,one,lead
MC-82,900,expired,owned,14:01,1,evt-82,auth_error,none,pending
MC-83,900,rotated,recovered,14:01,2,evt-82,accepted,one,lead
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Separate wall-clock timestamps from monotonic duration and lease logic. | Inventory every wall-clock and monotonic-clock dependency in token, cache, queue, retry, event-time, and deduplication code. | Clock offset and affected decision paths produce actionable telemetry. |
| Centralize token expiry, rotation, and safe redaction behavior. | Create valid-token, near-expiry, expired, rotated, queued, in-flight, retried, duplicate, and delayed-event fixtures. | No token value appears in logs, reports, or fixtures. |
| Preserve original event_time and event_id through bounded retries. | Simulate bounded forward steps and NTP slew through an isolated clock provider, never by changing the production host clock. | Forward steps do not create duplicate queue ownership or conversion events. |
| Make queue leases resilient to forward steps and worker restarts. | Capture token decision, lease owner, retry time, event_time, request, Meta response, event_id, and browser-server deduplication. | Rotated credentials and retries recover one deduplicated business outcome. |
Decision rule
Approve recovery when clock skew is observable, credentials rotate through the authorized path, leases do not duplicate work, original event identity is preserved, and Meta records one intended conversion.
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 |
|---|
| Near-expiry token | Clock steps beyond expiry | Clear auth failure and approved rotation |
| Active queue lease | Wall clock jumps forward | No second worker duplicates the event |
| Delayed event | event_time remains original | Age is explicit and not rewritten |
| Browser and server pair | Same event_id during retry | One deduplicated conversion |
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.
- Separate wall-clock timestamps from monotonic duration and lease logic.
- Centralize token expiry, rotation, and safe redaction behavior.
- Preserve original event_time and event_id through bounded retries.
- Make queue leases resilient to forward steps and worker restarts.
- Run isolated skew fixtures and verify one recovered business conversion.
Production verification checklist
- Clock offset and affected decision paths produce actionable telemetry.
- No token value appears in logs, reports, or fixtures.
- Forward steps do not create duplicate queue ownership or conversion events.
- Rotated credentials and retries recover one deduplicated business outcome.
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
- Changing production before preserving a reproducible fixture, timestamps, and the current result.
- Treating one successful screen, request, or export as proof that every downstream system agrees.
- Removing logs, identifiers, or rollback evidence before the owner and failure boundary are known.
- Testing only an administrator session instead of the roles, devices, consent states, and failure paths users actually have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and a narrow synthetic fixture. Perform destructive, version, cache-policy, queue, or schema changes on staging first, then promote the smallest proven change.
What evidence should be kept?
Keep versions, fixture IDs, UTC timestamps, request or export evidence, expected and actual results, the decision owner, rollback point, and the final clean verification. Redact personal data.
When is the work finished?
Finish when the canonical user path passes, downstream records reconcile, failure cases are understood, monitoring is in place, and an established page links to the new guide with useful context.
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, repair Meta CAPI reliability.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references