Test Whether Failed Uptime Emails Are Retried

Scope the test to a disposable notification route

Record the Uptime Kuma version, deployment image, email integration settings, relay version, and provider. Create a test monitor with a clearly named test notification destination and an inbox you control. Tell the receiving participants when the exercise will run.

Use a controlled relay or network rule scoped only to that test route. Do not disconnect the production monitor's entire network or block the organization's real mail server to answer a retry question. Preserve application and relay logs with credentials removed.

Capture four different milestones

The useful timeline contains the target state change, each notification attempt, the relay's acceptance of the message, and the final inbox arrival. The SMTP protocol (opens in a new tab) distinguishes acceptance from later delivery. An application log saying that a send function ran establishes less than an SMTP acceptance response.

Check retry settings carefully. A setting that retries an HTTP monitor before declaring it down says nothing by itself about whether a failed email send is retried. Use the project's troubleshooting guidance (opens in a new tab) to gather the relevant errors for the installed release without assuming all integrations behave identically.

Run the failure matrix

For each case, trigger one down transition and one later recovery. Restore the test route and watch whether both arrive, in what order, and with their original observation times. Keep the experiment open for the documented retry horizon or a clearly recorded observation period. Seeing no retry for two minutes does not prove none can happen later.

Interpret the result narrowly

If email retries occur only in memory, a process restart may lose pending work. If the relay durably accepted the message first, the relay's queue may own later delivery. If no supported queue exists, a transient send failure may require a different integration or additional delivery component.

Document observed behavior for the specific combination tested. Avoid turning the result into an unsupported statement about every Uptime Kuma version or every SMTP provider. Re-run after notification-library or integration changes.

Add reliability only where the evidence requires it

A persistent relay can separate local acceptance from upstream availability, but it adds storage, authentication, retry, and operational responsibilities. Monitor its queue age, disk capacity, and expiry failures. Retain event keys so retries do not create duplicate incidents in downstream bridges.

For urgent failures, keep an independently tested alternative channel or an outside deadline heartbeat. A delayed down message followed immediately by recovery is useful history, but it may no longer be a useful page. Tie late delivery to a current-state view so the responder can distinguish an active problem from a recovered one.