Detect Website and Email Failures Before Someone Tells Your Client

Imagine the message arriving in the middle of an ordinary working day:

One of our customers just sent us this screenshot. Why does our website say it is unsafe?

The screenshot is the browser warning everybody recognises: Your connection is not private.

The customer saw it first. They told your client. Your client is now forwarding it to you.

By then the failure is public and you are reacting on the client's schedule.

The same thing happens with email:

A customer says their message to our sales address bounced back as unreachable. How long has this been happening?

The sender sees the failure first: “address not found”, “mailbox unavailable” or “domain could not be reached.”

The web server can be up. Exchange can be healthy. Every internal dashboard can be green. A missing MX record, wrong nameserver, expired certificate or lapsed domain can still make those working systems unreachable from outside.

Your client did not discover the problem from an internal alert. Their customer received the failure and had to find another way to make contact.

Now the failure is public. Your client is embarrassed in front of their own customer, does not know how much business may have been missed, and immediately wonders what they are paying you to look after.

You no longer control the schedule

Five minutes earlier, you had a plan for the day.

Now you have to stop everything.

The certificate warning, broken DNS record or missing MX route may be straightforward to fix. That does not make the situation small. Once the client knows, the work becomes urgent regardless of what else you were doing.

You need to investigate immediately, send updates, coordinate with whichever supplier owns the affected system, and explain why nobody noticed first.

For an employee, the same escalation may reach a boss before it reaches the technical team. For an agency or MSP, it can put the entire client relationship under review.

The technical incident may last an hour. The doubt it creates can last much longer.

The failure may sit outside your contract

This problem is not limited to infrastructure you directly manage.

An MSP may not host the client's website. A web agency may not manage the client's mail service. A developer may have no access to the registrar. That does not make early visibility useless.

If the MSP sees that the public website or served certificate has failed, it can warn the client and direct the incident to the web team. If the web agency sees that an MX record changed or disappeared, it can tell the client to contact IT before customers start reporting bounced messages.

You do not need to own the repair to provide the early warning.

That is valuable because clients rarely think in supplier boundaries while something is broken. They see one business, one website and one email address. Whoever notices early looks proactive. Whoever learns from the client's customer looks absent.

Quiet monitoring beats another noisy dashboard

More alerts are not the answer.

An agency or MSP does not need AI to classify every vaguely similar registered domain as a critical risk. It does not need a growing bundle of unrelated security modules. That noise makes the real changes easier to miss.

The useful contract is simpler:

• watch the public DNS records that matter;
• watch the certificate actually served by the website;
• watch the domain's expiry state;
• stay quiet while the state is unchanged;
• alert when something meaningful changes.

This is outside-in monitoring. It checks what customers can actually reach rather than trusting that a provider dashboard, renewal job or configuration file must be correct.

A certificate may renew successfully on disk while the public endpoint continues to serve the old certificate. A DNS control panel may show the intended MX record while an authoritative server returns something else. A domain-renewal notice may be sitting in the inbox of somebody who left the company two years ago.

The public result is what affects the client.

A day earlier is a different kind of incident

Some warnings arrive days or weeks early: certificate expiry, domain expiry, and planned DNS changes that do not look right.

Other changes need attention as soon as they are visible: an MX record disappearing, nameservers disagreeing, or a critical DNS value changing unexpectedly.

Either way, an internal alert changes the nature of the work.

Instead of dropping everything after an embarrassed phone call, you can investigate, identify the responsible supplier, prepare the fix, and contact the client with an answer already in hand.

Sometimes the client never needs to see the failure at all.

That is the difference between reactive support and preventative monitoring.

A deliberately small tool for a costly problem

DNS Notify monitors DNS changes, SSL certificates and domain expiry from outside the provider account. It does not need DNS-provider credentials, does not change DNS, and does not use AI to manufacture extra findings. It is designed to stay quiet until the monitored state changes.

It costs £5 per month for five domains, or £50 per year. On the annual plan that is about 83p per domain per month.

The choice is not really between monitoring and doing nothing.

It is between:

• losing a client after their customers discover the problem;
• abandoning planned work and fixing it in a panic; or
• paying less than £1 per domain per month to hear about important changes as soon as possible.

Which would you choose?

You can also use the free DNS, MX, certificate and domain-expiry tools without creating an account.