Fixing Custom Certificate Emails That Don’t Send Automatically in Moodle

A learner becomes eligible for a certificate, it should be emailed automatically, and nothing arrives. This is the most common complaint about the Custom Certificate plugin (mod_customcert). The certificate template is usually fine; the failure is in the chain between “the learner is eligible” and “an email leaves the server.” This guide walks that chain in order so you can find where it breaks.

How mod_customcert actually issues and emails

A key correction to a widespread misconception: mod_customcert does not listen for a course-completion event. It has no event observer. Instead, a scheduled task (\mod_customcert\task\issue_certificates_task) runs on cron, by default every minute, and re-evaluates from scratch who is eligible for each certificate. When it finds a newly-eligible user, it issues the certificate and sends the email.

For the automatic email to fire, all of the following must be true for that user, as checked by the task:

1. At least one of the activity’s email settings is on (Email students, Email teachers, or Email others).
2. The user has the mod/customcert:receiveissue and mod/customcert:view capabilities.
3. The user satisfies the certificate module’s Restrict access conditions, and the module is visible to them.
4. The Required minutes in course threshold (if set on the activity) is met.
5. The user has not already been issued and emailed, and is not suspended.

Notice what is not on that list: there is no “course completion” check and no built-in “must receive a grade” check. Those only matter if you configured them as Restrict access conditions on the certificate. Diagnose in the order below.

Step 1: Confirm the email settings are actually on

In the certificate activity settings there is no single “Email certificate” toggle. There are three separate settings:

• Email students (Yes/No): emails the certificate to the learner.
• Email teachers (Yes/No): emails course teachers.
• Email others: a comma-separated list of additional email addresses.

If all three are off (the default for “Email students” is No), no automatic email is ever sent, regardless of eligibility. This is the first thing to check, and a common oversight.

Step 2: Confirm the access conditions are genuinely satisfied for the affected user

Because issuance is gated on the module’s Restrict access conditions and visibility, a restriction that looks satisfied but is not will silently prevent the email:

• Open the certificate activity’s Restrict access settings and confirm every condition (date, grade, group, activity completion) is genuinely met for the affected learner, not just for your admin account, which often bypasses restrictions.
• If the activity has a Required minutes in course value set, confirm the learner has actually accumulated that much time in the course. Until they have, the task will not issue.
• Confirm the affected user holds the capability to receive an issue (the student role does by default; custom roles may not).

If you expected “course completion” to drive issuance, remember it does not directly. If you want completion to gate the certificate, you must add it as a Restrict access condition (Activity completion / Grade) on the certificate module.

Step 3: Confirm cron is running and the task is healthy

Because issuance is driven by the scheduled task, if cron is not running, no certificate is ever issued or emailed. This is the most common real cause.

• Confirm cron is alive:

sudo -u www-data php admin/cli/cron.php

• Check the task under Site administration > Server > Tasks > Scheduled tasks, find Issue certificates task, and confirm it is enabled with a recent “last run”.
• Review Site administration > Server > Tasks > Task logs for failures on that task.
• Timing expectation: because issuance is polled on cron (the task defaults to every minute, but your site’s overall cron interval is the real floor), there is always a lag between a learner becoming eligible and the email arriving. If cron runs every 15 minutes, certificates arrive up to 15 minutes later. “It didn’t send” is sometimes really “it didn’t send instantly.”

Note: depending on the useadhoc setting, the email itself may be dispatched via a follow-up ad-hoc task (\mod_customcert\task\email_certificate_task) rather than inline. Either way it is cron-dependent.

Step 4: Confirm email actually leaves the server

If the user is eligible, the email settings are on, and the task ran without error, but mail still does not arrive, the problem is Moodle’s email transport, not the certificate.

• Send a test from Site administration > Server > Email > Outgoing mail configuration, using the “Test outgoing mail configuration” option at the bottom of that page.
• Check that the no-reply address and outgoing mail (SMTP) settings are valid. Mail sent “on behalf of” a strict-DMARC sender address is a known cause of silent drops at the receiving server.
• Inspect delivery logs at your mail provider. A message Moodle reports as sent but the user never receives has usually been dropped or spam-filtered downstream.
• For reliable transactional delivery, route Moodle mail through a dedicated service rather than a generic mail server. See our guide on Mailgun and Moodle integration for the transport setup; this guide covers the issuance chain that feeds it.

Edge cases worth knowing

• Retroactive eligibility: because the task re-evaluates eligibility every run, a learner who becomes newly eligible (for example after you relax a Restrict access condition) will be picked up and emailed on the next cron run automatically; there is no completion “event” to replay. The exception is a user who was already issued earlier (for example by a manual issue) with the emailed flag set, the task will not re-send to them.
• Already-issued users: the task de-duplicates on the issue record, so it will not email the same user twice for the same certificate. If you need to force a re-send, the existing issue has to be removed first.
• Template renders but no PDF / a broken PDF: that is a PDF-generation issue (fonts, layout, RTL text), separate from the delivery chain covered here.

The quick triage

For one affected learner, in order: Are the activity’s email settings on? Are its Restrict access conditions and any Required-minutes threshold genuinely satisfied for that user? Did the Issue certificates task run without error since they became eligible? Does a test email leave the server? The first “no” is your cause.

Solin specializes in Moodle certification, completion, and email delivery. Need help? Contact us.