Find an undelivered email
Somebody says they never received their reminder. Work through the chain in this order: each step tells you whether the problem is before or after it.
1. Is the notice switched on, and addressed to the right person?
Open LOOP → All messages. Check that the notice you expect is Enabled, and that its Recipient is the one you expect. Then open the certification and check the Notifications section: that it sends that notice at all, and that its day list contains the day the email should have gone out.
2. Did LOOP decide to send it?
Open User status and find the person. The Reminder column says whether anything was queued for them.
If nothing was queued, the notice was never due. The usual causes:
- the person's status never reached the state the notice is about;
- the certification is inactive;
- the certification does not send that notice;
- the licence is not active — queuing notices is one of the things a licence covers.
3. Is it still waiting?
Open LOOP → Mail queue. Items sit here until the mail queue task runs, which happens on every cron cycle.
| What you see | What it means |
|---|---|
| Pending, send time in the future | Normal. It is scheduled. |
| Pending, send time in the past | Cron is not running. Check Site administration → Server → Scheduled tasks. |
| Error, retries below the maximum | It has failed at least once and is waiting to be retried, one hour later. |
| Error, retries at the maximum | It has used up its attempts and is not retried automatically. |
The Retries column shows how many attempts have failed. The maximum is the Maximum retry attempts setting.
Each row offers Send to force it out now, and Delete to drop it.
An item that used up its attempts stays on this page
It stays visible, marked Error, instead of being deleted, and its row still offers a manual send once you have fixed whatever broke.
Two kinds of row are removed rather than kept, because no retry could help:
- one whose notice or whose subject has been deleted;
- an expiry warning still queued when the expiry it announces arrives.
The reason for both removals is written to the cron output.
4. Did the send itself fail?
Open LOOP → Message logs. Every attempt is recorded, with its outcome and, on failure, the error Moodle returned.
An error here is almost always the site's mail configuration rather than LOOP. Test it with Site administration → Server → Test outgoing mail configuration.
The Resend action on a row sends the same notice again. A resend names the course that is right today rather than the one recorded when the original went out.
5. Did it arrive somewhere you cannot see?
A notice addressed to the Manager goes to the certification's Manager emails, or failing that to the site-wide Fallback manager emails. Those addresses are configuration and not a manager relationship read from Moodle, so the notice goes to the same place for everybody covered by that certification.
With neither configured the notice has nowhere to go, and it is discarded rather than retried — the Home dashboard flags this as a Manager notice gap on the certification's row. Set an address and the next run queues it again.
On the Message logs page, Person concerned is who the notice is about, and Sent to email is where it actually went. For a Manager-addressed notice those are two different people.
Was the monthly report sent?
Open LOOP → Reports sent. One row per report, with the period, the address, how many certifications it covered, how many people it listed as out of compliance, and whether it was delivered.
A row marked Fallback address was delivered, but to the site-wide fallback rather than to anybody named on the certification — a gap in the configuration rather than in the mail.
The report counts people rather than naming them: each row links to that certification's status page, and two links at the foot of the email download the whole list, every certification in one file, as CSV or Excel. Both need a sign-in with permission to see the compliance record.