How to Get Alerts from HostTracker

2017-07-29 Updated: 2026-08-23

guide
product
HostTracker
website monitoring
uptime monitoring

Running monitors only pays off if you actually find out the moment something breaks, instead of noticing it hours later on a dashboard nobody was watching. HostTracker can alert you through ten different channels, and which one is right depends on the moment: a phone call gets attention at 3am that a chat message will not, while a chat message is plenty for a warning that can wait until morning. This is a walk-through of what channels exist, how to pick between them, which events actually trigger an alert, and how to set up a simple escalation so the right person hears about a problem before too much time passes.

The ten channels HostTracker can alert through

Email, SMS and voice call are the account basics. Email suits anything you can read at your own pace and want a record of; SMS gets a short text to you when you are away from a screen; an automated voice call reads out the site name and that it is down, for the alerts you cannot afford to sleep through.

Messengers add Telegram, Viber, Facebook Messenger, Google Chat and Discord, so a monitor can post into a chat your team already has open instead of adding one more inbox to check.

HTTP (webhook) posts the event as JSON to a URL you control. This is also how a Slack contact works under the hood - paste a Slack Incoming Webhook URL into an HTTP contact and the alert lands in a channel; see the Slack setup guide for the exact steps.

Web Push sends a browser notification straight to your desktop or phone with no channel to configure, once you have granted the browser tab permission to show notifications.

(If your account still has a Skype contact from years ago, it keeps delivering - Skype was retired for new contacts, so it no longer appears in the contact type list.)

Picking a channel for the situation

Email is easy to miss if it is buried in an inbox, but it is the right place for anything you want kept as a record. SMS and voice calls are built to interrupt you, which is exactly what you want for a real outage and exactly what you do not want for a minor warning. Messengers land somewhere your team is already looking without adding another login, which makes them a good middle ground. A webhook, including a Slack contact, is the best option once more than one person needs shared visibility into what is happening. Web push needs no setup at all, but it only reaches the device where the browser tab is open.

A practical pattern is to send everyday warnings to a channel that is easy to skim, like a messenger or a Slack channel, and reserve a phone call or SMS for the alerts that genuinely need someone to act right away.

Which events actually send an alert

Every contact you attach to a monitor subscribes to specific events on that monitor, not to the account as a whole. There are three events to choose from: Down (the monitor just failed), Up (it recovered), and Repeat (a reminder that it is still down). Down and Up mark the start and the end of an incident; Repeat is what keeps reminding you while an outage drags on, so you can leave it off a contact that only needs to know once, or on for whoever is actually working the problem.

A failed check does not send a Down alert by itself. HostTracker rechecks the site from other locations first, so a single flaky checkpoint does not fire an alert on its own - see distributed availability monitoring for how that multi-location check works.

If you run more than a handful of monitors, attaching the same contacts to each one individually gets tedious. HostTracker lets you save a set of contacts and their event subscriptions as a group, then apply that group to a monitor in one step instead of rebuilding the same list every time. It is worth setting up once you have more than two or three monitors sharing the same people.

Alerts are not the same as reports

The channels above cover alerts - Down, Up and Repeat, sent the moment an event happens. HostTracker separately offers periodic reports - daily, weekly, monthly, quarterly or yearly summaries of a monitor's uptime - and reports go to email contacts only. A monthly report also folds in the quarterly and yearly summaries, so subscribing to Monthly does not mean missing the longer-range ones. If you move your real-time alerts to Slack, SMS or a messenger, keep at least one email contact subscribed to reports if you still want a periodic roundup landing in an inbox.

Building a simple escalation

Every contact carries its own delay for Down alerts, chosen from a fixed set of options: instantly, 3 minutes, 5, 15, 30, an hour, 3 hours, 6 hours, 12 hours, or 24 hours. That delay is what turns a flat contact list into an escalation chain. Set the on-call person's Telegram or phone contact to instant, and a manager's contact to a delay of 15 or 30 minutes; if the site is still down when that delay elapses, the Down alert reaches the second contact too, arriving later but otherwise the same as the first one. A contact whose delay never comes due, because the site recovered first, is not bothered with either that delayed alert or the recovery notice for the same incident.

That is enough to build a straightforward chain: an immediate message to whoever is on call, then a phone call to a second person only if the problem outlives the first few minutes.

The same idea scales to a bigger team: a Slack or messenger contact set to instant for general visibility, an SMS contact at 15 minutes for the person who owns the service, and a voice call at an hour for whoever needs to be pulled in if it is still unresolved. The delay lives on the contact itself, not on the monitor, so the same three contacts and their delays carry over to every monitor you subscribe them to. If one monitor needs a faster or slower chain than the rest, subscribe it to a different set of contacts, or create a second SMS or voice contact with its own delay just for that case.