Meta CAPI event timestamps should represent the original business action consistently. JavaScript commonly produces milliseconds while many server integrations expect Unix seconds, creating a three-digit unit mismatch.
Use this for WordPress forms, WooCommerce purchases, CRM stages, and retry queues where events appear too old, too new, delayed, or unmatched.
Quick answer
Meta CAPI Seconds vs Milliseconds Event Time Test should be handled with a narrow evidence-first workflow: capture all clocks, detect units, normalize once, then verify the result before making broader changes.
What to check first
- Capture browser timestamp, server timestamp, stored event time, receipt time, and retry time.
- Count digits and convert sample values to an ISO date before upload.
- Preserve the original event time instead of replacing it during queue processing.
- Separate website lead time from later qualified-lead or sale time.
- Send controlled events to Test Events and compare logs, IDs, and displayed time.
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 all clocks | Capture browser timestamp, server timestamp, stored event time, receipt time, and retry time. | Uploaded event_time is a plausible Unix timestamp in seconds. |
| Detect units | Count digits and convert sample values to an ISO date before upload. | Retries preserve the original business-action time. |
| Normalize once | Preserve the original event time instead of replacing it during queue processing. | Browser and server events describe the same event and stable ID. |
| Preserve original time | Separate website lead time from later qualified-lead or sale time. | Test Events shows the intended time and one deduplicated result. |
Why this usually happens
- JavaScript Date.now returns milliseconds.
- Server Unix time functions commonly return seconds.
- A retry worker can restamp the event with processing time.
- CRM stage events can be confused with the original website lead.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
timestamp_test:
browser_ms: 1783861205123
normalized_seconds: 1783861205
iso_utc: 2026-07-12T13:00:05Z
digits_before: 13
digits_after: 10
event_id: lead_315_submit
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 all clocks
- Detect units
- Normalize once
- Preserve original time
- Test controlled events
What to tell the client or owner
Report time sources, units, conversion rule, event IDs, drift, retry behavior, and Test Events outcome.
Production verification checklist
- Uploaded event_time is a plausible Unix timestamp in seconds.
- Retries preserve the original business-action time.
- Browser and server events describe the same event and stable ID.
- Test Events shows the intended time and one deduplicated result.
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 event timing and deduplication.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references
Compare every clock when the timestamp is in the future
If the unit is correct but Meta still reports a future event, use the Meta CAPI server clock audit to compare browser, WordPress, NTP, PHP, queue, CRM, timezone, and receipt time.
Preserve the original event time through queue retries
Once the timestamp unit is correct, use the Meta CAPI queue-delay event-time policy to keep the original Unix seconds and event ID while recording queued, attempted, retried, and provider-received times separately.