Meta Conversions API event_time should represent when the business event occurred. If WordPress, the server, a queue worker, or CRM converts time incorrectly, Meta can receive a timestamp in the future and reduce confidence in the event or reject it.
Use this when Test Events or diagnostics reports future timestamps, when browser and server events do not deduplicate, or when delayed CRM events use the upload time instead of the business-event time.
Quick answer
Meta CAPI Future Timestamp Server Clock Audit should be handled with a narrow evidence-first workflow: capture every clock, check seconds vs milliseconds, audit timezone ownership, then verify the result before making broader changes.
What to check first
- Capture browser time, WordPress time, server UTC, queue created time, CRM business time, event_time, and Meta receipt time for one test ID.
- Confirm event_time is Unix seconds, not milliseconds, and record the raw numeric length.
- Check NTP status, system timezone, PHP timezone, WordPress timezone, database session timezone, and worker container time.
- Trace every parse, localization, conversion, serialization, and retry step that touches the timestamp.
- Correct the owning clock or conversion, then send one new test event instead of rewriting accepted production history blindly.
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 |
|---|
| Capture every clock | Capture browser time, WordPress time, server UTC, queue created time, CRM business time, event_time, and Meta receipt time for one test ID. | The event timestamp is not later than Meta receipt time beyond normal transport delay. |
| Check seconds vs milliseconds | Confirm event_time is Unix seconds, not milliseconds, and record the raw numeric length. | Browser and server events use the same business-event time and stable event ID. |
| Audit timezone ownership | Check NTP status, system timezone, PHP timezone, WordPress timezone, database session timezone, and worker container time. | Server, container, PHP, WordPress, database, and CRM clocks have documented ownership. |
| Trace queue conversion | Trace every parse, localization, conversion, serialization, and retry step that touches the timestamp. | New Test Events show the corrected timestamp without duplicate production conversions. |
Why this usually happens
- A 13-digit millisecond value can be interpreted as a date far in the future.
- A local time string can be labeled UTC without conversion.
- A queue worker can add an offset twice when rebuilding the payload.
- An unsynchronized server or container clock can lead browser and server evidence in opposite directions.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
date -u +%s
timedatectl status
wp eval 'echo current_time( "timestamp", true );'
# Expected event_time shape: 1783951200, not 1783951200000.
# Compare one event_id across browser, server, queue, CRM, and Meta Test Events.
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.
- Capture every clock
- Check seconds vs milliseconds
- Audit timezone ownership
- Trace queue conversion
- Send one fresh test
What to tell the client or owner
Share event ID, all captured clocks, raw event_time, digit count, timezone settings, NTP status, conversion code owner, and new Test Events result.
Production verification checklist
- The event timestamp is not later than Meta receipt time beyond normal transport delay.
- Browser and server events use the same business-event time and stable event ID.
- Server, container, PHP, WordPress, database, and CRM clocks have documented ownership.
- New Test Events show the corrected timestamp without duplicate production conversions.
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, repair Meta CAPI timing and deduplication.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references