Open Notification Audit and start with No attempt appears if the expected alert is missing. If the audit shows an attempt, use the section for skipped or failed or sent.
Start with the expected notification
Identify the credential, expected recipient, and approximate date. An entry in Operations is not proof that an alert was due or sent. For stale expiry or owner data, first follow Missing or stale inventory.
Not every expiry email comes from AppAlert. Microsoft Entra sends its own SAML certificate expiry emails 60, 30 and 7 days before expiry from azure-noreply@microsoft.com. Their recipients are set in Entra, not in AppAlert. See SAML signing certificate expired and Microsoft's federation certificate tutorial.
No attempt appears in Notification Audit
- Open Notification Audit, reset filters, and check the relevant UTC date range. History is retained for 365 days.
- In Organization Settings, verify the saved Email Notifications or Weekly Digest setting for the message you expected.
- Review the saved thresholds for that credential type. The queue's 90-day horizon does not mean every visible credential generates an email immediately.
- Check Admin notification emails and the saved owner-routing policy. A draft change is not active until its card is saved.
If inventory and saved settings appear correct, contact AppAlert support with the expected date and message type. See alert settings for configuration steps.
An attempt was skipped or failed
Read the recorded reason. No usable recipient calls for checking administrator addresses and the relevant Microsoft Entra owner records. An empty digest may have no content to send. A suppressed recipient needs its suppression cause resolved before sending again.
An alert run falls back to admin recipients when every owner recipient is suppressed or permanently rejected. Temporary delivery failures retry. A bounce reported after provider acceptance affects later eligible alerts, not the current alert. See owner routing.
For a failed attempt, note its time and outcome and contact support if the problem persists. Repeatedly sending test messages does not repair the underlying delivery or routing problem.
Sent appears but the email is missing
Sent means provider acceptance. Check Delivery for a later outcome, then check junk mail, quarantine, and organizational mail filtering with the recipient's mail administrator. A delivered provider outcome is not a read receipt.
If delivery is delayed or bounced, use the reported outcome to investigate the recipient address and mail system. Notification history explains these stages.
Resolve recipient suppression
For an incorrect administrator address, update Admin notification emails and save. For an incorrect owner address, correct the relevant owner record in Microsoft Entra and allow AppAlert to sync again.
Check Recipient suppression status in Notification Audit. Provider suppression can affect an address across organizations. Ask AppAlert support to review the suppression after the address or delivery problem has been resolved. For a complaint, first confirm that the recipient wants future notifications. When continued delivery is appropriate, AppAlert support removes the address from the email provider's suppression list. A verified removal event clears AppAlert's local suppression state; confirm that Recipient suppression status shows Available before trying again. Changing settings does not itself remove a provider suppression.
Check a saved template with a test
When available, Send a test notification checks the saved template and administrator delivery path using synthetic data. It does not exercise real credential eligibility or direct owner routing.
Use notification records and recipient details only as needed for diagnosis. Data handling describes the information AppAlert retains.