Hansen IT Solutions

Monitoring that tells you about problems in a place you don’t look is just a very elaborate diary. Email was the default notification channel for so long that many products still treat an inbox as the destination — but if you’re anything like most technical teams, the place you actually look all day is a chat app. HITS Scout alerts natively to Discord, Slack, and email, and this article is about wiring those up so alerts land where they’ll actually be seen — and seen by the right people.

Why chat-native alerting wins

Email alerts have three structural problems. They arrive in a queue that’s already overwhelming. They’re invisible to everyone except the recipient — if the on-call person is at lunch, the alert is just sitting there. And they don’t sit next to the conversation about the problem. An alert that lands in the same channel where your team is already talking gets triaged in seconds, discussed in place, and resolved with the full context attached to the thread.

Both Discord and Slack give you this via incoming webhooks — a URL that accepts a JSON payload and posts it to a channel. HITS Scout speaks webhook natively, so setup is minutes, not a project.

Setting up the Discord side

In Discord, server settings → Integrations → Webhooks gives you a webhook URL per channel. Create one channel for monitoring alerts, create the webhook, paste the URL into HITS Scout’s notification settings for your monitors. The alert messages arrive pre-formatted with the monitor name, what failed, and when — enough to start triage without leaving the chat.

One Discord-specific tip: create a dedicated #alerts channel, not a #general webhook. Discord channels are cheap, notification settings are per-channel, and the point of the exercise is that people who want alerts can have them at full volume while everyone else’s chat stays readable. Nobody joins a server to watch a bot page forty times an hour.

Setting up the Slack side

Slack’s version is functionally identical: an incoming webhook app installed to your workspace, pointed at a channel, and the resulting URL pasted into HITS Scout. The workspace admin permission gate is the only friction, and it’s a five-minute conversation if you’re not the admin.

Where Slack earns its keep is channel structure. A pattern that works well for teams running multiple properties: one alerts channel per environment or client — #alerts-prod, #alerts-clients, #alerts-infra. Each HITS Scout monitor routes to the channel where its audience lives. When something breaks, the people who care see it, and the people who don’t aren’t trained to ignore your alerts.

Keep email in the loop — as the archive, not the alarm

We’d still enable email alongside chat, with one deliberate role: the paper trail. Chat scrolls, channels get archived, and when you’re reconstructing an incident timeline two weeks later for a client or a post-mortem, a searchable alert mailbox is worth having. Email is a terrible pager and an excellent filing cabinet — use it for what it’s good at.

Thresholds and channels work together

If you read the previous article on tuning, you know HITS Scout verifies your primary URL before alerting on link failures and supports per-monitor thresholds. The routing pattern that pairs well with that:

• Revenue-critical monitors → the channel your on-call person actually has notifications on for, strict thresholds, immediate alerts.
• Everything else → a team channel, lenient thresholds. It gets seen during business hours, which is the correct urgency for a docs site that got slow.

This gives you a two-tier system that matches how incidents actually work: a small number of things that are allowed to interrupt you, and a larger set of things that are watched but shouldn’t interrupt anyone’s dinner. The chat routing and the threshold tuning are doing complementary work — thresholds decide whether an alert fires, channel routing decides who hears it.

The honest test

Here’s how to know your alert setup is working: deliberately break something. Add a monitor pointed at a URL that 404s, let it fire a real alert into your real channels, and watch what happens. If the alert arrives in seconds, is readable, and generates a “looking into it” — the wiring is right. Delete the test monitor and trust the system.

The monitoring that saves you is the monitoring you believe, and the monitoring you believe is the monitoring you’ve seen work.

Alert channels are configurable on every plan, including the two-monitor free tier — hitsscout.link/signup.

Next in this series: building a public status page your customers can read without an account — and why every client site should have one.

Every monitoring setup eventually gets tuned, and every tuning session starts with the same two dials: how often do we check, and how bad does it have to look before we get told. Get those right and monitoring feels like a calm colleague who taps you on the shoulder when something actually matters. Get them wrong and it’s a smoke alarm going off every time you make toast — which you’ll eventually silence, and then it can’t tell you about the fire either.

Here’s how we think about both dials in HITS Scout, and the settings we’d recommend for the common cases.

Check intervals: the trade-off nobody escapes

HITS Scout supports per-monitor check intervals from 30 seconds to 24 hours. The interval you pick buys you detection speed and spends site checks and alert noise. The honest math on detection: with a 30-second interval, your average time-to-detection for a hard outage is 15 seconds; with 5 minutes, it’s two and a half minutes. Both numbers are fine for most things — the question is what actually needs sub-minute detection.

Our recommendations after running these combinations in production:

• Revenue path (checkout, API, customer login): 30 seconds. This is what the Enterprise interval is for. If this tier of thing goes down, every minute has a dollar figure attached.
• Primary websites and apps: 1 minute. The Pro default. Fast enough that an outage is caught before most visitors notice, slow enough that a single dropped packet doesn’t page anyone.
• Marketing sites, blogs, docs: 5 minutes. The free-tier interval. For content sites, five minutes of downtime is a rounding error; the link crawler and slow-response tracking do more useful work here than raw speed.
• Archival and low-stakes properties: hourly or slower. If a site’s job is to exist rather than to be up-to-the-second, a 24-hour check confirms it’s still alive without wasting anyone’s attention.

Thresholds: how bad before it’s bad

The second dial is what counts as a failure worth knowing about. HITS Scout’s alerting is threshold-based and configurable per monitor, and it has one piece of built-in intelligence that saves a remarkable amount of noise: before alerting on link-check failures, it verifies your primary URL.

The logic is simple and effective. If deep links are failing but the primary URL is healthy, you have a link problem — report it, but it’s not an outage. If the primary URL is failing too, the whole site is down — that’s one clear alert, not forty confused ones. This distinction alone eliminates most of the 3am false-positive pages that make people distrust their monitors.

Slow-response thresholds work the same way: pick a response-time ceiling that’s realistic for the site. A WordPress blog on shared hosting has no business alerting at 500ms — set the threshold at a level where an alert genuinely means degradation, like 3–5 seconds. The goal is that when your phone buzzes, your first reaction is “this is real”, not “probably nothing again”.

Consecutive-failure counts: the persistence tax

Most transient failures are exactly that — transient. A BGP reconvergence, a container restart, a burst of traffic that clears in ninety seconds. Alerting on the first failed check means alerting on all of these. Requiring two or three consecutive failures before alerting filters the majority of blips at the cost of one or two extra intervals of detection time. Our default recommendation: require 2 consecutive failures for 1-minute monitors, 1 for 30-second monitors — the faster interval already amortises the blips, and on the slow tiers the extra wait isn’t worth it.

A worked example

Here’s the setup we’d suggest for a typical small-business stack, roughly $13/month of HITS Scout:

• Customer-facing app (Enterprise, 30s): strict thresholds, alert immediately after 2 consecutive failures. This is the one that can wake you up.
• Main website (Pro, 1m): moderate thresholds, alerts to the team channel rather than on-call.
• Docs site, blog, staging (Free, 5m): lenient thresholds — these can wait for morning.

That’s eight monitors across three tiers, each tuned so that alert volume correlates with actual importance. The whole point of a monitoring stack is to convert site problems into informed action — and the tuning stage is where you decide whether “informed” is true.

Every plan has per-monitor interval and threshold configuration, so you can build this exact structure starting on the free tier: hitsscout.link/signup.

Next in this series: getting those alerts into Discord and Slack, and structuring channels so the right people see the right problems.

In the intro article we mentioned that HITS Scout’s link crawler is the feature that gets technical people’s attention. Here’s the full story, because the design is genuinely different from the usual “crawl everything at 2am” approach — and the difference matters if you care about your site’s load profile and how fresh your link data actually is.

The problem with the nightly full crawl

Traditional site checkers work like search-engine crawlers: they walk your entire site in one burst, compile a report, and go to sleep until tomorrow. That model has two failure modes. First, the burst itself — a crawler hitting every page on your site within a few minutes can look a lot like a slow-burn DoS, especially on modest shared hosting or a small VPS. Second, the staleness: a link that breaks at 9am gets reported tomorrow morning, after a full day of visitors finding it for you.

How the incremental crawler works

HITS Scout takes the opposite approach. Each monitor maintains a running inventory of every link on your domain — discovered as it encounters them, not in one upfront sweep. Then, every check cycle, alongside the regular uptime check of your primary URL, the crawler visits the oldest link it hasn’t looked at recently. One link per cycle. Steady, flat, boring — exactly what you want hitting a production site.

Think of it as a round-robin with a memory. Over time, every link in your inventory gets rechecked on a predictable cadence, and the effective coverage interval per link is simply the number of links multiplied by your monitor’s check interval. The math is worth doing for your own site, so here’s a worked example from ours: one of our monitors tracks roughly 26,000 links on a Gitea instance. At a 5-minute check interval, every link gets revisited about every 90 days. Drop the interval to 30 seconds and full coverage compresses to around 9 days. That’s the tuning dial: interval × link count = coverage cycle.

There’s a subtlety here worth appreciating: link importance is front-loaded automatically. Your homepage and primary navigation get checked every single cycle as part of uptime monitoring — the incremental crawl is spending its budget on the long tail of deep pages, which is precisely where breakage hides.

Same-domain only, and why that’s a feature

The crawler tracks same-domain links only. It won’t follow your outbound links to other people’s sites. That’s a deliberate boundary, and it’s the right one: your crawl stays bounded (the inventory can only grow as large as your own site), your crawler’s impact stays on infrastructure you own, and your link reports stay relevant — a broken outbound link on someone else’s site is interesting trivia, not your incident.

It also keeps the inventory honest. If the crawler wandered the open web, your “link count” metric would be meaningless — some fraction of it would be someone else’s problem. With same-domain tracking, the number of links in your inventory is a real measurement of your own site’s complexity, and you can watch it move as your site grows.

What each check records

Every link visit captures the HTTP status code and the response time, not just an up/down bit. That turns your link report into a performance dataset:

• Broken links — hard failures with status codes, so you can tell a dead page (404) from a server error (500) from a redirect that’s silently eating link equity (301 chains).
• Slow endpoints — pages that return 200 but take four seconds to do it. These never trigger a traditional uptime alert, but they’re exactly the pages that quietly bleed visitors and hurt your search rankings.
• Intermittent wobbles — the 503 that appears once an hour under load and vanishes before you can look. A single visit misses these; a rolling inventory with history catches the pattern.

Practical setup advice

A few rules of thumb we’ve settled on after running the crawler against everything from small marketing sites to that 26k-link Gitea:

• Match interval to site size. A 40-page marketing site at 5-minute checks gets full coverage in under a day and a half. A large documentation tree wants a faster interval if you want week-level coverage — or accept 90-day coverage and rely on alerting for the important pages.
• Watch the inventory number. If your link count suddenly jumps, either you shipped a big change or something is generating URLs (calendar pages, faceted search, session IDs in links). Both are worth knowing about.
• Fix in batches by depth. Broken-link reports are naturally ordered by when the crawler found them, which correlates with how deep in the site they are. Fix the shallow breakage first — it’s what visitors hit most.

The incremental crawler is included on every plan, including free — two monitors, full link inventories, no credit card. Point one at your biggest site and let the first report arrive: hitsscout.link/signup.

Next in this series: tuning check intervals and alert thresholds so you find real problems without paging yourself into oblivion.

Most uptime monitors tell you a comfortable lie. They ping your homepage every few minutes, get a 200 back, and paint your dashboard green. Meanwhile a CMS update quietly broke half your internal links, a plugin started 500-ing on a form submit, and the only people who know are your visitors — because they’re the ones hitting the 404s.

That gap is why we built HITS Scout. It’s a website monitoring platform that does both jobs properly: multi-region uptime monitoring and incremental link crawling across your whole site, with alerts that land where your team already lives.

The link crawler that doesn’t hammer your site

The feature that gets technical people’s attention is the crawler. HITS Scout doesn’t recrawl your entire site every night at 2am like a sitemap tool. It maintains a live inventory of every link on your domain and checks the oldest unvisited link each cycle. The result is a slow, steady crawl that spreads load across your check interval instead of dumping it in one burst — and it means link freshness is continuous, not a nightly report that’s stale by morning.

Every check records the status code and response time, so your link report isn’t just “broken or fine” — you can see the 301 chains, the slow endpoints, the intermittent 503s that only appear under load. And it tracks same-domain links only, which keeps crawls bounded to your site. Your crawler isn’t wandering off into third-party territory, and your link graph stays clean.

To give you a sense of scale: we dogfood HITS Scout on our own infrastructure, and one of our monitors currently tracks north of 26,000 links on a single Gitea instance. Incremental crawling is what makes that practical.

Multi-region uptime, not single-datacenter optimism

A monitor in one region tells you your site is up from that region. That’s a meaningful difference, and anyone who’s debugged a “works for me” incident knows it. HITS Scout runs distributed monitoring agents across multiple regions, so a regional DNS hiccup, a CDN edge problem, or a routing weirdness shows up as what it is — a regional issue — rather than either being missed entirely or paging you as a full outage.

Check intervals are configurable per monitor, from 30 seconds up to 24 hours. You can watch your production app like a hawk while checking the marketing site every few hours. Each monitor tracks uptime percentage and full downtime history, so when the client asks “was it down last Tuesday?”, you have the answer instead of a shrug.

Alerts that don’t cry wolf

Alert fatigue kills monitoring setups faster than any outage. HITS Scout’s alerting has a verification step built in: before it alerts on link-check failures, it verifies the primary URL first. If your whole site is down, you get one clear alert, not forty. If the homepage is fine but deep links are broken, you get the link report — a different signal, treated differently. Thresholds are configurable so you can tune sensitivity per monitor.

Notifications go out via Discord, Slack, or email — whichever channel your team actually watches. No proprietary app to install, no vendor portal to log into at 2am.

Status pages and the activity timeline

Every monitor can feed a public status page — a curated, customer-facing view with live uptime, response times, and recent incidents. Viewers don’t need an account, which is the entire point of a status page. If you run client sites, this is the difference between “we’re looking into it” and a link you can paste into an email.

Behind the scenes, the activity timeline gives you a unified feed across all your monitors: outages, slow responses, and link issues in one chronological stream. When three sites on the same host start acting up within the same ten-minute window, the timeline makes the correlation obvious instead of something you reconstruct from three separate dashboards.

Built like a proper distributed system

For the infra-curious: HITS Scout is a Go backend with small, single-purpose workers — an alert worker, usage worker, metrics worker, pruner, and agent cleanup — coordinated through a queue, with monitoring agents as an independent tier that can be scaled by region. The capacity system is built on measured data: real checks-per-minute throughput, per-agent utilisation, and queue depth, so the platform’s own health dashboard tells you the same kind of truth it tells you about your websites. The frontend is React and TypeScript, and the whole stack deploys cleanly on Docker Compose or Kubernetes.

We’re a DevOps consultancy, and this architecture is the one we’d want to inherit: boring components, clear separation, no distributed monolith pretending to be microservices.

Pricing that fits a homelab budget

The free tier gives you 2 monitors with 5-minute checks and 7 days of retention — genuinely free, no credit card. Pro is $4/month for 5 monitors at 1-minute checks and 30 days retention, and Enterprise is $9/month for 10 monitors at 30-second checks and 90 days retention. That’s cheap enough to point monitors at every side project, every client site, and the stuff you’re not paid enough to care about but would still feel bad losing.

Start monitoring in about two minutes

Sign up at hitsscout.link/signup, add a URL, and HITS Scout starts crawling and uptime-checking immediately. Your first broken-link report will probably arrive before you’ve finished your coffee — most sites have at least a few skeletons in the link closet.

We’ll be writing follow-up articles here covering specific features in depth: tuning check intervals, setting up alert channels, building a public status page, and getting the most out of the link reports. If you’ve got questions in the meantime, the docs and signup live at hitsscout.com.