When Gravity Forms stores the entry, WordPress received and processed the submission. That narrows the missing-email problem to notification selection, message creation, a background queue, the mail transport or the recipient system.
Protect the saved enquiries first, then trace one synthetic entry using its entry ID and timestamp.
Triage entries before changing settings
Review entries submitted since the last known delivered notification and assign unanswered leads to authorised staff. Entries can contain personal or sensitive data, so avoid sending bulk exports through ordinary email or attaching them to support tickets.
Create a labelled test with no real customer information. Record its entry ID, form ID, submission time, expected notification and recipient.
Do not delete failed entries or queues until their diagnostic value and business status are understood.
Confirm the notification event
Open the active form under Settings and inspect Notifications. Gravity Forms can trigger notifications on form submission, payment completion, payment failure or other events provided by add-ons.
A notification waiting for a payment event will not run merely because an entry was created. Check the entry timeline and payment status before treating this as a mail fault.
Verify the public page uses the form ID you are editing; duplicated forms can have similar names but independent notifications.
Review recipients and routing
Check Send To Email, routing rules, CC and BCC. A routing rule may depend on a field value that was renamed, removed or stored differently from its visible label.
Use a fixed, authorised domain address for From Email and place the visitor address in Reply-To. Do not send as the visitor’s Gmail or company domain.
Test each business-critical route separately. Removing routing conditions globally can disclose enquiries to the wrong team.
Inspect conditional logic
Notification conditional logic can suppress mail while the entry still saves normally. Compare the entry’s stored values with the rule operators and expected values, including case, whitespace and multi-select choices.
Run one synthetic entry that should match and another that should not. Record which notification IDs execute rather than assuming every enabled notification runs.
If a field changed after the notification was created, rebuild only the broken comparison and retain a configuration rollback.
Use Gravity Forms logging carefully
Enable Gravity Forms logging for the relevant components only long enough to reproduce the problem. Correlate log lines with the form and entry IDs. Protect logs because they may contain field values, recipient addresses or provider responses.
Look for notification suppression, invalid recipient data, add-on errors and the result of the WordPress mail call. Disable and securely remove verbose logs when the investigation ends.
Do not enable WordPress debug display for public visitors.
Check background processing
Some Gravity Forms add-ons and integrations process feeds asynchronously. Review scheduled actions, WP-Cron and server cron health. A growing backlog or repeatedly failed task can explain why entries appear immediately while messages do not.
Preserve the queue state before retrying it. Repair the runner or failed dependency, then release pending work at a controlled rate to avoid sending duplicates or hitting provider limits.
Check hosting PHP errors and resource limits at the original submission time.
Follow the mail beyond WordPress
Search the WordPress mail log for the test recipient and timestamp, then find the same message in the SMTP or transactional provider. Record acceptance, deferral, bounce or suppression plus the message ID.
If accepted, ask the authorised recipient administrator to inspect quarantine, transport rules, aliases and shared-mailbox restrictions. WordPress success is not final delivery.
Inspect a delivered copy for SPF, DKIM and DMARC alignment.
Verify recovery without creating duplicates
Submit a fresh labelled entry after the narrow repair. Confirm the correct event and notification ID, one mail attempt, provider acceptance and final mailbox arrival. Check Reply-To, routing branches, payment events and attachments where relevant.
Request urgent repair if leads are accumulating, payment-driven notifications are uncertain or queue retries may duplicate messages. Share entry IDs, timestamps and redacted errors—never payment data, passwords or full customer entries.