Reminder Jobs, Delivery Logs, and Retries

DayTidy Free supplies lifecycle email templates. Notification Operations in DayTidy Pro adds delivery logs, eligible recipient retries, and scheduled reminders. Keep those responsibilities separate when deciding which module a site needs.

Configure a reminder

1. Verify Pro authorization and enable Notification Operations in the module settings.
2. Open DayTidy → Notifications → Templates and create or edit the reminder template.
3. Choose Booking Reminder Before Start as the trigger. In Notification Timing, enter Reminder Time and choose minutes, hours, or days before the first session.
4. Enable the intended recipient contexts and write their subjects and messages using the supplied placeholders.
5. Save the template and check eligible test bookings under Notifications → Reminder Jobs.

For a 24-hour reminder, use 24 and Hours before first session. A booking whose first session has already passed the intended reminder time is not equivalent to a new future reminder opportunity. Check the actual job state rather than assuming every existing booking receives a new message.

Reminder execution depends on WordPress cron, an eligible booking/template, and working mail transport. Review jobs after session moves or template changes. A cancelled or otherwise ineligible booking should not be used as evidence that a reminder ought to send.

Read delivery logs

Open DayTidy → Notifications → Overview and inspect Delivery Logs. Filters include booking reference, recipient email, status, and source. Sources distinguish event, test, retry, and reminder attempts.

Result	Interpretation
Sent	Accepted by WordPress or the active mail transport
Failed	The transport rejected the attempt
Skipped	Eligibility or configuration prevented an attempt

Sent is not proof of final inbox delivery. DayTidy does not track final bounce/spam placement, opens, or clicks here. Use your mail provider’s evidence for the next stage of delivery.

Retry deliberately

Only failed delivery logs can be retried. Inspect the failed attempt’s recipient, template, source, and error first. Fix transport or configuration problems before selecting an eligible retry. A retry works from the recorded recipient context; do not assume it resends to every recipient of the original event. Recheck the resulting log to distinguish the new attempt from the original one.

Use a controlled inbox for tests, and avoid repeated retries that could send duplicate customer messages. If the retry action is absent or rejected, check permissions, module availability, recipient validity, and current template eligibility. See email troubleshooting for the diagnostic sequence.