Troubleshoot missing Drecha emails and delayed notifications

Start with the saved record

Email is a notification channel, not proof that a submission or booking was stored.

1. For Forms, open Drecha Forms → Entries and find the entry.
2. For Events, open the event booking or appointment manager and find the reservation.
3. Confirm the recipient address saved on that record.
4. Only ask the visitor to try again if no record exists and the original request genuinely failed.

Drecha Forms commits the entry before queuing email. Events creates the booking or appointment before calling WordPress mail. Repeated submissions can therefore create unnecessary follow-up work even when the original record is safe.

Diagnose Drecha Forms notifications

No email job exists

Open the entry detail and review its status and notification configuration.

• Spam entries intentionally do not queue notifications.
• A notification must be enabled and have at least one valid recipient.
• A respondent confirmation needs an enabled confirmation and a valid email value from its configured form field.
• Conditional notification routing is a Pro feature; confirm that Pro access is active when that rule is expected to select a route.

Correct the form settings for future submissions. Changing settings does not retroactively create jobs for an existing entry.

The email log says failed

1. Open the failed attempt and read the recorded WordPress mail error.
2. Correct the sender, recipient, or WordPress mail transport.
3. Use the retry action only after the cause is fixed.
4. Confirm that a new queued attempt completes.

Drecha Forms jobs make up to four automatic attempts. Retry delays grow from one minute and are capped at one hour. A manual retry resets a terminal failed email job so it can run again. Do not click Retry repeatedly while the transport is still broken.

Test email succeeds but the message never arrives

wp_mail() returning success means WordPress handed the message to its configured mail system. It does not prove inbox delivery.

1. Check the recipient's Spam, Junk, Quarantine, and filtered folders.
2. Check the mail or SMTP plugin log for provider acceptance or rejection.
3. Verify the From domain, SPF, DKIM, and DMARC with the mail provider or host.
4. Send to a second address at another provider.
5. Treat the provider's delivery response as the delivery evidence, not the WordPress success message alone.

Restore delayed Forms background jobs

Drecha Forms processes queued notifications with a one-minute WP-Cron schedule. WordPress normally starts cron work when the site receives traffic, so a low-traffic site can process a job later than expected.

1. Open the Entries screen and look for the warning that WP-Cron is disabled.
2. Check wp-config.php for DISABLE_WP_CRON.
3. If it is true, configure a real server scheduler to request wp-cron.php regularly.
4. If it is false but the site has little traffic, configure the same real scheduler for predictable processing.
5. Confirm that the next queued job moves out of Pending and that its email log is updated.

A real cron runner should call WordPress's cron entry point; it should not invoke Drecha database jobs directly. Ask the host for its supported WordPress cron setup.

Configure WordPress mail instead of a second mail server

Drecha uses WordPress wp_mail(). It is designed to work with established SMTP or transactional-mail plugins that hook into WordPress mail.

1. Install and configure one reputable WordPress mail transport, following its provider documentation.
2. Use an authenticated sender on a domain the provider permits.
3. Send the transport plugin's own test message.
4. Send a Drecha Forms test email.
5. Submit a new form and confirm the entry, queued job, Drecha email log, and provider log.

Avoid running two SMTP plugins at the same time. They can compete to change the sender and transport.

Diagnose Drecha Events email

Core event confirmations, cancellations, not-going acknowledgements, and appointment messages call wp_mail() directly after the related record change. Unlike Drecha Forms, the current Events Free core does not provide a per-message delivery log or a general retry queue for those core messages.

1. Confirm that the booking or appointment exists.
2. Confirm that its customer email is valid and that the action normally sends mail—for example, a public Going reservation or confirmed appointment.
3. Check the WordPress mail/SMTP plugin log at the same timestamp.
4. Test WordPress mail through that plugin.
5. Correct the transport, then test with a new controlled booking on staging or a clearly identified test event.

Do not change a real customer's status merely to force another email. Contact the customer directly when necessary and retain the booking reference.

Events Pro automation jobs such as waitlist processing use their own five-minute cron schedule and retry failed automation work up to five attempts. If a Pro automation email is delayed, confirm the Pro license, WP-Cron, and the relevant automation activity rather than assuming the core booking email uses that queue.

Troubleshoot common outcomes

Forms entry exists but there is no notification

Check Spam status first, then enabled notifications, recipient addresses, conditional routes, and the job list. If a job exists, work from its status and error instead of resubmitting.

Event booking exists but neither side received email

The booking is still the authoritative record. Check the saved customer address and the site-wide mail log. Drecha Events does not operate an independent SMTP server.

Jobs run only when an administrator visits

That pattern indicates traffic-driven WP-Cron. Configure a real server cron trigger and leave WordPress cron processing intact.

Mail reaches Spam

Use an authenticated sender that matches the website's mail domain, verify domain authentication, and avoid misleading From addresses. Content changes alone cannot fix a provider authentication failure.