The failure that reports itself as nothing
Most product failures announce themselves. A page throws an error, a button does nothing, something turns red. Notification email has the opposite shape: when it breaks, everything looks normal. Visitors keep leaving messages, the messages keep being stored, the dashboard keeps listing them, and the only thing that changed is that the email telling you a message arrived no longer reaches anybody.
From the outside that is indistinguishable from a quiet week. Nobody files a support ticket about an email they did not receive, because they do not know it was sent. The reasonable conclusion from where you sit is that live chat is not generating much, and the reasonable response is to stop checking.
Two things make this worse than an ordinary outage. It is permanent, because the mechanism that stops delivery does not retry. And it is silent on both sides, because the mail system knows the address is dead but has no way to tell the person who chose it. That combination is how weeks pass.
The check described here exists to break that silence in the one place you will actually see it, which is your own dashboard.
Which addresses are actually checked
The check looks at the addresses your notifications are genuinely sent to, not at every address in your account. That is a narrower list than people expect, and it is worth knowing which one is in play.
If you have set a feedback email address, that is the address used. If you have not, the account email is used instead. Whichever applies, the value is split on commas and semicolons, so a field holding several recipients is treated as several addresses and each is examined separately. Anything without an at sign is ignored rather than reported as broken.
The practical consequence is that the address under scrutiny may not be the one you log in with. An account created years ago by someone who has since left, with a feedback address pointing at a departed colleague's mailbox, is exactly the configuration this catches. It is also the configuration most likely to have quietly died, which is the point.
If you are not sure which address your account is using, that is itself worth resolving before anything else. Customizing the emails your live chat sends covers where those settings live and what each one governs.
Two conditions, only one of them obvious
An address is reported as a problem for one of two reasons, and they are quite different in character.
The first is suppression. When a message to an address hard bounces, or the recipient marks mail as a complaint, or somebody unsubscribes, the address is added to a suppression list and nothing is sent to it again. This is standard, correct mail practice and it protects your sending reputation. It is also the case most worth surfacing, because suppression is permanent: nothing about it expires, and no later message will retry. An address suppressed in June is still suppressed in December unless somebody removes it.
The second is repeated recent failure. If five or more messages to an address failed to deliver in the last seven days and not a single one succeeded in that window, the address is reported. This catches the case where suppression has not kicked in yet but the address is plainly not working, most commonly because the domain no longer resolves at all.
The banner names the address and the reason rather than saying that notifications are failing. That distinction matters more than it sounds. An account may have several notification recipients, and knowing which of them is dead is the entire difference between a fix that takes a minute and an afternoon of guessing.
Why it is deliberately reluctant to warn you
Both thresholds are set to under-report rather than over-report, and the reasoning is worth stating because it explains cases where you might expect a banner and not get one.
The failure threshold is five, not one. A single bounce is not a dead mailbox. Mailboxes fill up, servers have bad afternoons, greylisting delays a message that arrives fine on the second attempt. Treating one transient failure as a broken address would put a warning in the dashboard of customers whose email works, and a dashboard that cries wolf teaches people to ignore it. The first false alarm costs more than the tenth true one earns.
The success test is stricter still. Even with failures above the threshold, a single successful delivery to that address in the same seven days cancels the warning entirely. An address that is delivering at all is working, and the failures are something else: one bad recipient in a multi-address field, a temporary problem, a large attachment rejected. Sending you to change a setting that was never broken is its own kind of harm.
The consequence to hold on to is that no banner is weaker evidence than a banner. A warning means something is definitely wrong. The absence of one means nothing crossed a deliberately conservative bar, which is not the same as everything being fine.
The check fails open, on purpose
This runs on dashboard page loads, which puts it in a position to do real damage if it misbehaves. Two design decisions follow from that.
The result is cached per account for thirty minutes, so the underlying queries do not run on every request. Notification health is not a fast-moving number, and a dashboard that adds database work to every page view for a banner that changes twice a year is a bad trade. If you fix an address and want to see the banner clear, expect to wait rather than to refresh.
The whole check also fails open and silently. Every query is wrapped so that any error at all, including the tables it reads not existing on a given installation, produces no warning rather than an error page. A health check that can break the dashboard is worse than no health check, and a warning banner is never important enough to justify taking the page down with it.
The price of that choice is the same ambiguity as above, one level deeper: silence can mean healthy, or it can mean the check could not run. If you have positive reason to believe your notifications are not arriving, treat the absence of a banner as no evidence at all and test delivery directly.
What to do when the banner appears
The two reasons need different responses, so read the wording before acting.
If the address bounced and delivery was stopped, the address itself is the problem. Confirm the mailbox still exists and still accepts mail from outside your organisation. A common cause is a person who has left, where the mailbox was deleted or converted to a forwarder that no longer forwards. Point the notification setting at a real, monitored address, ideally a shared one rather than an individual's, so the next departure does not repeat this.
If the address was unsubscribed, somebody clicked an unsubscribe link in a notification email. That is usually accidental, and sometimes deliberate by a person who found the volume annoying and did not realise what else it would switch off. Resolving it means both re-enabling the address and having a conversation about volume, because unsubscribing will otherwise happen again. If nobody on your team recognises the click at all, it is worth knowing that unsubscribe links are signed and unsigned ones are throttled precisely because a suppression somebody else caused looks exactly like this — what stops someone unsubscribing your address for you covers the mechanism.
If the message is that recent messages could not be delivered, check the domain before the mailbox. Repeated total failure with no successes usually points at something structural: a domain that expired, a mail record that was changed during a migration, a server that was decommissioned. A quick test is simply sending mail to that address from an unrelated account and seeing what comes back.
Whatever the cause, verify the fix rather than assuming it. Leaving a message on your own site through the widget is the honest end-to-end test, and it exercises exactly the path that was broken. What gets captured when a visitor leaves a message describes what should arrive when it works.
How MyLiveChat fits
Offline messages and chat copies are only useful if they reach a person, so the delivery path is treated as part of the feature rather than as infrastructure somebody else worries about. The check reads your real notification addresses, reports suppression and sustained failure, names the address and the reason, caches for half an hour, and stays quiet when it cannot be sure.
It is a warning, not a monitor. It will tell you when something is definitively broken, and it will not tell you that everything is working. For the messages themselves, chat transcripts and history are stored in your account regardless of whether the email arrived, which means a notification failure costs you speed but never the message itself.
Two related habits close the loop. Finding and following up on missed live chats covers catching what slipped through while the email was dead, and live chat notifications and alerts covers the agent-side signals that are a faster path than email in the first place.