Reminders are "fire and forget" — once a template is active and an event schedules a send, you don't think about it daily. But when a customer says "I never got my MOT reminder", the History and Scheduled tabs at Workshop Settings → Reminders are where you check what actually happened. History lists every log (filterable by status); Scheduled shows just the queued rows that haven't fired yet.
What's in each log row
- Scheduled date — when this send is due (or was due)
- Channel — email or SMS
- Recipient — the customer's name (plus their business name, if any)
- Message — the one-off title or template name, falling back to the message body
- Status — one of
scheduled,sent,failed,cancelled,skipped - Error message — on
failedrows, hover the red "Error" label to see the cause (e.g. "Insufficient credits")
Scheduled rows also carry actions: Send Now, Edit recipient, Cancel (and Delete for one-off customs).
Why "resolved body" matters
Each log row stores the message body with placeholders already resolved, so if a customer reports a confusing message the record shows what was actually built for them — placeholders may have resolved to something you didn't expect (e.g. a missing customer name leaving "Hi ," at the top). In the History table the body is shown for one-off sends; template-driven rows display the template name instead.
The five statuses
| Status | Meaning |
|---|---|
scheduled | Queued, not yet due |
sent | Successfully dispatched |
failed | Tried to send but failed. Reason in errorMessage |
cancelled | Manually cancelled (e.g. customer rebooked before the send fired) |
skipped | More than 14 days overdue when the cron ran (e.g. after an outage), deliberately not sent late |
There's no separate bounced or insufficient_credits status — those manifest as failed with the cause in errorMessage.
"Send now"
A scheduled row exposes a manual Send now action that fires immediately instead of waiting for the cron — useful when a customer asks for the reminder right now. Note that only scheduled rows can be sent now; failed rows aren't retryable through this path (the action explicitly rejects any row whose status isn't scheduled). To re-attempt a failed send, schedule a fresh one-off.
Retention
Logs are retained indefinitely. They're cheap (one row per send, no attachments) so there's no automatic pruning.