A domain name alert may report an incident that is already visible or a risk that is still preventable. To respond correctly, we must look at three elements: the current impact, the time available and the extent of the problem.
Not all alerts have the same severity
An expired certificate and a certificate that expires within 20 days concern the same component, but not the same situation. In the first case, visitors can already see a security warning. In the second, the service still works and there is still time to verify renewal.
Before you intervene, ask yourself four questions:
- Is the service currently inaccessible or degraded?
- Are visitors, clients or collaborators affected?
- Can the problem get worse quickly?
- Do several services depend on the component concerned?
Level 1: Critical alert
An alert is critical when an essential service is already unavailable, presents a visible safety risk or prevents significant activity.
- the domain no longer resolves;
- the site returns a persistent error or abnormal content;
- the TLS certificate has expired or does not correspond to the domain;
- mail servers are no longer reachable;
- an unexpected DNS modification diverts traffic.
First confirm the incident from another network or monitoring location. Then identify the last change, restore a known-good configuration if the origin is known, and then check the recovery from the outside.
In a critical situation, the initial objective is to restore a stable service. The full analysis of the cause comes next.
Level 2: Important alert
An important alert does not necessarily cause an immediate failure, but it can become critical if it is ignored: certificate nearing expiry, incorrect redirect, unexpected DNS record, inconsistent email authentication or intermittent failure.
Set a near-term deadline and assign an owner. Do not close the alert after a successful check: compare several observations and confirm that the expected configuration has been fully restored.
Level 3: Preventive alert
A preventive alert draws attention to an improvement or a sufficiently distant deadline. It must not interrupt the ongoing operations, but it must still be tracked.
Add the action to a scheduled list with a verification date. An alert without an owner or deadline often becomes an emergency.
A simple grid to decide
| Situation observed | Priority | Expected action |
|---|---|---|
| Service unavailable, abnormal content or visible security alert | Critical | Confirm, contain and restore immediately |
| Service available but near risk or malfunction | Important | Diagnose and correct within a short time |
| No current impact and timeframe sufficiently distant | Preventive | Plan, document and check again |
If several alerts appear at the same time, start with the one that affects the largest number of services. A widespread DNS outage takes priority over a secondary email-policy improvement.
Adapt priority to the affected component
DNS: check the extent before changing
The DNS can simultaneously affect the site, emails and other services. Compare the current value to the expected configuration and check whether the problem affects a subdomain or the entire zone. To review the role of the main entries, see the DNS record guide.
HTTPS: distinguish availability from the correct response
A successful HTTP code does not guarantee that the right content is displayed. Check final destination, expected content and redirections. Article Why HTTP 200 is not enough details this case.
TLS certificate: check date and name covered
Treat immediately a certificate refused by the browsers. For a future deadline, check automatic renewal and schedule a new check. Find the key points in the TLS certificate guide.
E-mail: separate receipt and authentication
A reception breakdown is generally critical. An SPF, DKIM or DMARC error may gradually degrade deliverability. To understand their roles, see SPF, DKIM and DMARC explained simply.
Avoiding false positives without ignoring incidents
An isolated alert may come from a temporary problem with the control network. Quickly confirm from another observation point, then compare the result to a known reference: expected IP address, expected content, certificate date or documented DNS configuration.
Repeat testing must complete the analysis, not replace it.
Document what's normal
Keep the main DNS records, the main address of the site, the redirects, the suppliers used, the services authorized to send emails and the backup procedure. This reference accelerates the diagnosis and avoids the error of correcting a legitimate configuration.
More readable alerts with TechAtelier Protect
TechAtelier Protect collects the essential signals of a domain to help distinguish an urgent anomaly from a risk to be anticipated.
Create a Protect accountMonitor so you can act at the right time
Good monitoring does not aim to generate more alerts. It must provide enough context to decide what is broken, what is at risk and what can wait.
By classifying alerts according to their impact, their timing and the extent of the services involved, you reduce unnecessary interventions while responding more quickly to real incidents.
Published on 19 August 2026.