Gravity Forms evidence can appear in browser time, WordPress site time, PHP or server time, UTC, Action Scheduler, cron, an add-on queue, webhook receiver, email provider, and CRM. Without one canary ID and normalized timestamps, teams can connect unrelated lines or conclude that an async job never ran.
Use this when a Gravity Forms entry is created but a notification, feed, webhook, CRM record, payment action, or background task arrives late, runs twice, or seems to disappear from logs.
Quick answer
Submit one synthetic canary with a unique non-personal identifier. Record browser, WordPress, server, database, cron, feed, webhook, mail, and provider timestamps with their source time zones, then normalize copies to UTC. Join records by entry ID, canary ID, feed ID, request ID, and provider message ID before changing retry or schedule settings.
What to check first
- Record the WordPress timezone, PHP default timezone, server log timezone, database timezone, worker scheduler, and external provider display timezone.
- Create a synthetic canary ID that can safely appear in the form, entry meta, webhook, mail subject, and external test record.
- Enable only the Gravity Forms logging components needed for validation, notifications, and the affected add-on.
- Capture entry creation, feed queue, cron dispatch, HTTP request, provider acceptance, retry, and completion timestamps.
- Redact personal data, disable temporary logging, remove test records, and verify backup or object-storage copies follow retention policy.
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 |
|---|
| Inventory every clock | Record the WordPress timezone, PHP default timezone, server log timezone, database timezone, worker scheduler, and external provider display timezone. | The canary has one joined timeline from validation through the expected external outcome. |
| Create one safe canary | Create a synthetic canary ID that can safely appear in the form, entry meta, webhook, mail subject, and external test record. | Every timestamp has a source zone or explicit UTC conversion. |
| Enable narrow components | Enable only the Gravity Forms logging components needed for validation, notifications, and the affected add-on. | Retries and duplicate attempts are distinguishable by request and provider IDs. |
| Normalize and join evidence | Capture entry creation, feed queue, cron dispatch, HTTP request, provider acceptance, retry, and completion timestamps. | Temporary logs and synthetic records are removed according to the documented retention path. |
Test scenarios to run
Run the same controlled fixture across these branches. Record the expected result before the test so a surprising response is visible immediately.
| Scenario | Fixture | Expected result |
|---|
| Immediate notification | Canary creates an entry and synchronous email | Entry and mail IDs join within the expected request window |
| Async feed | Canary queues one webhook or CRM feed | Queue, dispatch, request, and provider times normalize into one ordered path |
| Temporary failure | Receiver returns the documented retryable response once | Retry keeps the canary ID and creates a distinct request ID |
| Permanent rejection | Fixture triggers a non-retryable provider validation error | Queue closes with a clear reason and no duplicate external record |
Why this usually happens
- A date without an offset can represent different moments across systems.
- Async jobs run after the request that created the entry and can use another process or host.
- Retry systems can create several log lines and provider IDs for one logical feed.
Field notes
- Use UTC as the comparison layer but preserve original timestamp and offset.
- Do not place an email address, phone number, or customer name in the canary ID.
- Record queue and retry state before manually replaying the job.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
canary_id=gf-canary-20260804-01
entry_id=4821
site_time='2026-08-04 08:30:12 -0500'
server_time='2026-08-04T13:30:12Z'
feed_id=7
request_id=req_91ac
provider_id=msg_44fe
result=delivered
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.
- Inventory every clock
- Create one safe canary
- Enable narrow components
- Normalize and join evidence
- Disable logs and verify retention
Decision rule
Do not replay or change a queue until the existing attempt, retry state, provider outcome, and idempotency behavior are known. A missing local line is not proof that the external action failed.
What to tell the client or owner
Provide the canary ID, entry ID, component names, original timestamps and zones, normalized UTC timeline, feed ID, request ID, provider ID, retry state, and cleanup proof.
Production verification checklist
- The canary has one joined timeline from validation through the expected external outcome.
- Every timestamp has a source zone or explicit UTC conversion.
- Retries and duplicate attempts are distinguishable by request and provider IDs.
- Temporary logs and synthetic records are removed according to the documented retention path.
Mistakes to avoid
- Do not compare unlabeled local timestamps as if they are UTC.
- Do not enable every logging component for an open-ended period.
- Do not manually replay a feed before checking idempotency and provider state.
- Do not use real personal data as the correlation key.
Questions teams ask during testing
Why is the provider timestamp later than the WordPress log?
Queue delay, network time, provider processing, and timezone display can all contribute. Normalize timestamps and follow IDs.
Can the entry ID be the only correlation key?
It helps locally, but external systems may not retain it. Carry a safe canary plus request and provider IDs.
When should logs be disabled?
As soon as the controlled reproduction and required evidence are complete. Then confirm local, backup, and external retention behavior.
When HandL WP should help
HandL WP can design a privacy-safe canary, correlate Gravity Forms, cron, webhook, mail, and provider evidence, isolate the missing stage, and close temporary logging cleanly.
If this is active on a production site, trace a Gravity Forms async failure.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references