Start your 7-day free trial, card not charged until it ends
Browse all topics

Alerts, history & notifications

Monitoring · Last updated 9 August 2026

This is the hub for how TLDTrack tells you things. Whenever a check finds a problem it raises an alert, and notifications are how that alert reaches the right people, by email, text message, push notification, or a team channel such as Slack or Microsoft Teams.

What it is

When a check finds a problem it creates an alert, which is stored and appears on your Alerts screen and your dashboard with a severity, and can be marked read or resolved. Notifications are how that alert reaches people, by email, SMS, push, and connected channels such as Slack, Microsoft Teams or your own webhook.
Read more
Every alert carries a severity, so the urgent ones stand out, and can be marked read or resolved as your team works through them. Notifications are the delivery side: you set up notification contacts, each of whom can be reached by email or SMS text message, and you decide which contacts hear about which kinds of alert. Push notifications go to the mobile app. Alongside contacts you can connect whole team channels, Slack, Microsoft Teams or your own webhook, so alerts land where your team already works. Together they separate two jobs cleanly: the alert is the shared record of what needs attention, and the notification is the nudge that gets a person to look at it.

Why it matters

Monitoring is only useful if the right person hears about a problem in time to do something about it.
Read more
A check that spots a problem but tells nobody is worthless, and a flood of alerts that reaches everybody is almost as bad, because people learn to ignore it. The point of this system is to get the right message to the right person on the channel they will see fastest, while keeping a tidy shared list of what still needs doing and what is already handled. That is what turns raw monitoring into something your team can actually act on.

Alerts: the shared record

When any check finds a problem, TLDTrack creates an alert and keeps it. Alerts appear in two places: on your dedicated Alerts screen and on your dashboard. Each alert carries a severity, so the urgent ones stand out from the minor ones, and each one moves through a simple lifecycle:

  • Critical alerts are the ones that usually mean something is broken or about to be, like a site being down. They are counted separately so they cannot get lost.
  • Warning and informational alerts are worth knowing about but rarely an emergency, such as a tracking code changing.
  • Mark an alert read once someone has seen it, so the team knows it is not being missed.
  • Mark it resolved once it is dealt with, so everyone can see what is handled and what still needs work.

Because alerts are stored, they build up a history you can look back on, and the unread, unresolved ones are what drive the counts you see around the app.

Notifications and contacts

Notifications are how an alert leaves the screen and reaches a person. You set up notification contacts, each with an email address, a mobile number, or both. There are three ways an alert can reach someone:

  • Email, included as standard on every plan.
  • Push notification, on paid plans, sent to everyone signed in to the TLDTrack mobile app on your account rather than to individual contacts.
  • SMS text message, on paid plans, to UK mobile numbers only, which uses SMS credits (a small balance you top up).

Every alert a check raises lands on the Alerts screen and dashboard, and many types also send a push notification. The more important alert types, such as a site going down, a certificate expiring or a monitored value changing, also go out by email and, for contacts who have opted in and have credit, by SMS. That keeps the urgent things loud on the channels people watch, without emailing everyone about every minor note.

Contacts are not the only route. You can also connect team channels, Slack, Microsoft Teams or any webhook endpoint of your own, which receive alerts as a channel rather than person by person. Those are covered in the alert channels section below.

SMS uses credits, email and push do not

Email and push notifications are included. SMS messages draw on SMS credits, a small balance you top up when you need it, and each text sent uses one. If your credit runs out, email and push keep working as normal, so you are never left with no way of being told. Adding a mobile number to a contact for the first time earns you a free SMS credit to try it with.

Choosing who hears what

You do not have to send every alert to everyone. Each contact has its own per-type preferences, so you can decide, channel by channel, which kinds of alert they receive. The categories include:

  • Uptime, when a site goes down or recovers.
  • DNS changes, for changes to email authentication records (SPF, DKIM and DMARC). DNS record change emails go to the account owner and admins instead.
  • Blacklist and malware, for Google malware flags. Blacklist listing emails go to the account owner and admins instead.
  • Expiry, for domain renewal reminders.
  • Hosting (WHM), for server and account warnings.
  • WordPress changes.
  • Content & visual, which covers content, visual, tracking and error changes.

SSL certificate expiry emails are not in this list. They go to every active contact with an email address.

That lets you route sensibly: a developer might take the technical and monitoring alerts by email and SMS, while an account manager takes only the ones a client cares about. Nobody is buried in notices that are not theirs to action.

Alert channels: Slack, Teams and webhooks

As well as reaching people directly, alerts can be delivered to the places your team already talks: a Slack channel, a Microsoft Teams channel, or any HTTPS endpoint of your own. You manage these under Settings > Alert channels. Each destination has a name, a webhook URL, and its own filters, so you can send everything to one channel and only the critical alerts to another. Alert channels are available to admin users on the Starter, Pro and Agency plans.

  1. 1
    Open Settings and go to the Alert channels tab.
  2. 2
    Under Add destination, choose the type: Slack, Microsoft Teams, or a generic webhook.
  3. 3
    Give it a name your team will recognise, for example "Ops channel".
  4. 4
    Paste the webhook URL and choose which alerts it should receive (see the filters below), then save.
  5. 5
    Press Test on the new destination. TLDTrack sends a sample alert so you can confirm it arrives before relying on it.

Where the webhook URL comes from depends on the type:

  • Slack. Use an incoming webhook URL. You create one from Slack's developer site, not from inside the Slack app itself, and it takes about two minutes. The steps are below.
  • Microsoft Teams. Use a workflow webhook URL. Teams has retired its old connectors, so instead you create a Workflow from the "Post to a channel when a webhook request is received" template, point it at your channel, and copy the URL it generates.
  • Generic webhook. Any HTTPS endpoint you control. TLDTrack POSTs a JSON body containing the event name, the alert (its id, type, severity, title, message, domain and created-at time) and a sent-at timestamp, with three headers: X-TLDTrack-Event, X-TLDTrack-Timestamp and X-TLDTrack-Signature. The signature is a sha256 HMAC of the raw request body, so your endpoint can verify each delivery really came from TLDTrack.

Getting a Slack webhook URL, step by step

Slack no longer offers incoming webhooks from inside the Slack app, so you create a small Slack app instead. It stays private to your workspace and does nothing except receive the alerts you send it.

  1. Go to api.slack.com/apps and sign in to the workspace you want alerts in.
  2. Click Create New App, then From scratch.
  3. Give it a name such as TLDTrack, pick your workspace, and click Create App.
  4. In the left sidebar choose Incoming Webhooks, and turn Activate Incoming Webhooks on.
  5. Scroll down and click Add New Webhook to Workspace.
  6. Choose the channel the alerts should go to, then click Allow.
  7. Copy the Webhook URL it shows you. It starts https://hooks.slack.com/services/.
  8. Back in TLDTrack, paste it into the URL field, give the destination a label, and save.

One webhook is one channel

A Slack webhook URL always points at a single channel, chosen at step 6. If you want uptime alerts in one channel and journey test failures in another, repeat these steps for the second channel and add it as a second destination, then use the alert group tickboxes to decide what each one hears.

The webhook signing secret is shown once

When you create a generic webhook destination, TLDTrack generates a signing secret and shows it a single time. Store it somewhere safe straight away; it is what your endpoint uses to verify the X-TLDTrack-Signature header, and it cannot be viewed again later.

Every destination has two filters, so a channel only hears what it should:

  • Alert groups. Tick the groups the destination should receive, such as uptime, DNS or SSL expiry. Leaving every box unticked means it receives all alerts.
  • Minimum severity. Choose whether the destination receives everything, warnings and critical only, or critical only.

Matching alerts are normally delivered within about a minute of being raised. If a delivery fails, the failure is shown on that destination's row in Settings, so a silent channel never goes unnoticed. For safety, webhook URLs that point at private or internal addresses are rejected.

Escalation: when nobody responds

Notifications get an alert seen; escalation is the safety net for when nobody looks. On the same Settings > Alert channels tab, switch escalation on and choose a window in minutes (between 5 and 120, 15 by default). If a critical alert has not been opened by anyone within that window, it is re-sent once to your escalation contacts.

  • Mark people as escalation contacts using the Escalation toggle on each contact in your notification contacts matrix.
  • If no contacts are marked for escalation, the alert is re-sent to all matching contacts instead, so it never falls into a gap.
  • Escalation works across email, SMS (which uses SMS credits) and your connected channels.
  • Each alert escalates once, so a long-running incident does not turn into a stream of repeats.

Cutting the noise

Good alerting means fewer, more meaningful messages. If every alert feels equally loud, people stop reading them, so TLDTrack lets you turn down the noise while keeping the signal:

  • Silence DNS alerts for individual record types, so you keep the ones that matter and drop the ones that do not.
  • Mute a specific changed item, such as a particular tracking-code change or client-side error, for a while when you already know about it, so the same thing stops re-notifying.
  • Point each contact's preferences at only the categories they should own, so the right people get the right things in the first place.

The aim is that every alert you do receive is one worth reading.

Turning a module off hides its alerts too

If you switch a whole module off in Settings, that hides all of that module's alerts and stops its notifications entirely, not just quietens them. The underlying record is kept, so history returns if you switch the module back on, but nothing is sent while it is off. Only turn a module off if you truly want to stop watching it. See modules for how this works.

Setting up who is told

  1. 1
    Open Settings and go to your notification contacts.
  2. 2
    Add a contact with a name and an email address, a mobile number, or both. Adding a mobile number the first time earns a free SMS credit.
  3. 3
    Choose, for each channel, which categories of alert that contact should receive, so they only hear about the things they own.
  4. 4
    Save. From then on, matching alerts are delivered to that contact on their chosen channels, on top of always appearing on the Alerts screen.

What you will see, and what to do

When a problem is found, it appears on your Alerts screen and dashboard, and your chosen contacts are notified on their channels. Work through the list by severity: open the critical ones first, mark each read so the team knows it is being handled, and mark it resolved once it is fixed. If a particular kind of alert is firing more than it is worth, reach for the muting options above, or tighten a contact's preferences, rather than switching the whole module off, so you keep the checks running but stop the nagging. To learn about a specific source of alerts, see DNS monitoring or uptime monitoring. To manage which modules are on in the first place, see modules.

Where to set this up

Good to know

  • Every alert is stored and shown on the Alerts screen and dashboard, whether or not it also sends a notification.
  • Email and push are included; SMS draws on SMS credits, one per text. The free plan sends email alerts only.
  • Slack, Teams and webhook destinations are managed by admin users under Settings > Alert channels, on the Starter, Pro and Agency plans. Each destination can filter by category and severity, and has a Test button.
  • A generic webhook's signing secret is shown once, at creation. Store it then; it verifies the X-TLDTrack-Signature header on every delivery.
  • With escalation on, a critical alert nobody has opened within your chosen window (5 to 120 minutes) is re-sent once to your escalation contacts.
  • Core alerts like domain expiry, certificate expiry, DNS and blacklist are always shown, even if you have other modules switched off.
  • Turning a module off in Settings hides its alerts and stops its notifications for the whole team, which is different from muting a single item.
Available on:FreeStarterProAgency

Was this guide helpful?

If anything is unclear or missing, tell us and we will improve it.

Contact support