Hansen IT Solutions

This is the last article in our HITS Scout series, so let’s do the thing marketing pages are structurally incapable of: an honest breakdown of the plans, what each one is actually for, and the decision process for picking between them. If you’ve read the earlier articles — the incremental crawler, interval tuning, Discord/Slack alerting, status pages, and multi-region monitoring — this is where it becomes a shopping decision.

The three plans

Everything in HITS Scout — link crawling, multi-region checks, Discord/Slack/email alerts, status pages, the activity timeline — is on every plan. The plan controls three knobs: how many monitors, how fast they check, and how long we keep your history.

• Free — $0/month: 2 monitors, 5-minute checks, 7 days retention.
• Pro — $4/month: 5 monitors, 1-minute checks, 30 days retention.
• Enterprise — $9/month: 10 monitors, 30-second checks, 90 days retention.

No credit card to start, and the free tier isn’t a trial — it doesn’t expire. Billing runs through Stripe, so upgrades, downgrades, and cancellations behave the way you’d expect from anything Stripe-backed.

Who Free is actually for

Two monitors with 5-minute checks and a week of history covers more ground than people expect. The honest fit: personal projects, the homelab front door, a portfolio site, a blog you’d like to know about before a client emails you. Point one monitor at the site itself and you get uptime plus the full incremental link crawl. That’s a genuinely complete monitoring setup for the things that don’t earn money but would still embarrass you if they quietly died.

The 7-day retention is the real limit. It’s fine for “is it up now and what happened this week”. It’s not enough for SLA conversations, month-over-month comparisons, or “was it down last Tuesday”. If you’ve ever needed history, you already know you’re not a Free user.

Pro: the small-business default

Five monitors at 1-minute checks with 30 days of retention is the shape of a typical small business: the main site, the app, the email, maybe a staging box, with a slot spare. At $4/month, it’s priced below the coffee you’ll drink while reading your first broken-link report.

The upgrade that matters most from Free to Pro is the retention. Thirty days is the minimum horizon for spotting patterns — the slow degradation that builds over weeks, the recurring wobble every Monday morning, the response-time creep after each deploy. A week of data shows you incidents; a month shows you habits.

Enterprise: when minutes have dollar values

Ten monitors at 30-second checks with 90 days of retention. The honest framing: this tier is for when you can name the cost of a minute. Checkout flows, customer-facing APIs, the client site with an SLA attached. At 30-second intervals, average outage detection is 15 seconds — and with alert verification built in, that speed doesn’t come at the price of false pages.

The 90-day retention is the length of a quarter. That’s deliberate: when the client asks for evidence of uptime over the contract period, the data is still there, with the timeline to back it up.

How to actually decide

Forget the feature matrix and answer three questions:

• Would an outage cost money, or just pride? Pride: Free. Money: Pro or Enterprise.
• Do you need to prove uptime to anyone? Anyone includes your future self in an argument with a host. Yes → 30 or 90 days retention. No → 7 days is fine.
• How many things do you genuinely run? Count real properties, not aspirations. Two → Free. Five-ish → Pro. A portfolio of client sites → Enterprise, and if you’re past ten, that’s a conversation.

And since the free tier is permanent, the decision isn’t a commitment — set up two monitors today, live with it for a week, and upgrade only when you hit a wall you can name. That’s how we’d want to be sold to, so it’s how we sell.

Start here: hitsscout.link/signup — two monitors, full link crawling, multi-region checks, alerts, status pages. No credit card.

That wraps the series. If you’ve been reading along, thanks — and if you’re monitoring with something that only watches your homepage, your link graph is waiting to tell you what it thinks.

Two of the most common support tickets in the website business are invisible to a single-region monitor: “the site is slow but only for our Melbourne office” and “three client sites broke at the same time”. The first is a regional issue — a CDN edge, a DNS resolver, a routing path. The second is a shared-infrastructure issue — same host, same upstream, same fate. HITS Scout’s architecture is built to catch both, using multi-region monitoring agents and a cross-monitor activity timeline. This article covers how the two work together.

The single-region blind spot

A monitor in one datacenter answers a narrower question than most people realise: “is this site reachable from here?” Every big public outage story has a regional chapter — the AWS outage that took one availability zone, the BGP incident that blackholed routes for one corner of the internet, the CDN misconfiguration that served errors to one continent. If your single monitor happens to sit in the healthy region, your dashboard says green while half your customers stare at an error page.

HITS Scout runs monitoring agents as a distributed tier across multiple regions. Each check cycle, your monitors are verified from different geographic vantage points, so a regional problem shows up as what it is: a failure from some regions, health from others. That signature is instantly more useful than a bare “down” — it tells you the site is up and the path is broken, which points you at DNS, CDN, or routing rather than at your own server.

Agents are the architecture, not an afterthought

For the infra-minded: the agents are an independent tier from the API and workers — a Go service that picks up check work, executes it from its region, and reports results back. The platform tracks agent health by heartbeat freshness (an agent that stops checking in is itself an incident), and capacity is managed on measured data — real checks-per-minute throughput, per-agent utilisation, queue depth — rather than optimistic assumptions. The same philosophy as the product itself: the monitoring system monitors itself with the same honesty it applies to your websites.

What this means practically: when a region’s agent population has a problem, checks fail over to healthy regions, and the capacity system notices the deficit. Your monitor’s data comes from somewhere real, and “somewhere real” is plural by design.

The activity timeline: pattern recognition for humans

The second half of the picture is the activity timeline — a unified, chronological feed of everything noteworthy across all your monitors: outages, slow responses, and link issues, in one stream.

Its value shows up in exactly the scenario that’s hardest to debug from individual dashboards: the coordinated incident. You run six client sites on the same host. At 14:07, three of them start timing out. Opened one monitor at a time, that’s three separate tickets, three investigations, maybe three different engineers looking at the same root cause from three angles. Opened on the timeline, it’s one obvious event: three monitors, same host, same ten-minute window, one incident. You go straight to the host instead of debugging the same outage three times.

This is the quiet superpower for anyone running a portfolio of sites — agencies, MSPs, or just people with a lot of side projects on shared infrastructure. Correlation that would take a spreadsheet and a hunch is just… visible.

Reading the timeline well

A few habits that make the timeline earn its place in your day:

• Scan for clusters before reacting. One red entry is an incident; three red entries in the same minute are a diagnosis. The timeline turns shared infrastructure failures from three tickets into one.
• Slow-response entries are early warnings. The timeline doesn’t just track outages — a run of slow entries on a monitor is often the leading edge of resource exhaustion: disk filling, connections saturating, the database degrading under load. Outages make the noise; slowness makes the pattern.
• Check the timeline before answering “was it down?” When a client asks about last Tuesday, the cross-monitor history is right there with timestamps and durations — no reconstruction from logs, no guessing.

Both features, all plans

Multi-region checks and the activity timeline aren’t gated behind the top tier — they’re core to how HITS Scout watches every monitor on every plan, starting with two free monitors at hitsscout.link/signup.

Next in this series, the final article: a straight breakdown of the plans — free, Pro, and Enterprise — and which one actually fits your stack.

There’s a moment every consultant and managed service provider knows: a client calls to ask if their site is down, you check, it is, and the call becomes two problems — the outage, and the fact that the client found out from their own customers. The status page exists to delete that second problem. HITS Scout publishes public status pages for any set of your monitors — no login required for viewers — and this article is about building one that does its actual job: keeping customers informed before they have to ask.

What a HITS Scout status page is

A status page is a curated, public view over a selection of your monitors. It shows live uptime status, response times, and recent incidents for each monitor you include. Viewers just need the URL — no accounts, no “sign in to see if we’re down”, which is the single most absurd pattern on the modern web.

The key design decision is that inclusion is manual. Your status page is not a dump of every monitor you run — it’s a deliberate subset of the services your audience actually depends on. Internal tooling, staging environments, and the manager’s dashboard that’s always slow don’t belong on it. The page answers one question for one audience: are the things I care about working?

Why the status page outlives your website

Here’s the detail that matters and that most people miss: your status page is hosted on HITS Scout’s infrastructure, not yours. When your primary site falls over entirely — DNS meltdown, host outage, the classic full-fat disaster — the status page keeps serving from wherever it lives, completely indifferent to your misfortune.

This is why the footer link pattern works: put your status page URL in your site footer, your support email signature, your on-hold music if you have it. When things break, the first place customers look still works, still loads fast, and still has your incident history on it. A status page that only works when everything else does is a decoration.

Structuring one for client sites

If you run sites for other people — an agency, an MSP, a consultancy like us — one page per client is the clean default. Each client’s page contains exactly their monitors: their website, their app, maybe their email if you’re watching that too. The client gets a URL they can bookmark and, better, hand to their own customers during an incident. You’ve just given every client a professionalism upgrade they didn’t have to build.

For your own product, structure the page by user-facing service, not by internal architecture. Customers don’t care that “api-cluster-3” is degraded; they care that “Login” and “Dashboard” are affected. Name monitors after what your users experience.

What viewers see during an incident

The incident timeline on a status page is doing quiet, important work: it converts your monitoring data into a story a non-technical reader can follow. An entry that says a monitor went down at 14:32 and recovered at 14:58 is reassuring in a way that “we’re investigating intermittent issues” never is. Specific timestamps read as competence — someone is watching this thing closely enough to know.

Response-time history earns its place on the page the same way. Even when nothing is “down”, a visibly slow week on the graph sets honest expectations and quietly justifies the maintenance you’re about to do.

The trust compounding effect

Most status pages sit empty and green for months, and it’s tempting to conclude they’re doing nothing. They’re doing something slower: every day the page is up and accurate, it compounds a little trust. Customers learn it exists, learn it’s honest (uptime percentages with visible dips are more believable than 99.99% claims with a suspiciously flat graph), and learn that when something breaks, there’s a place to check before opening a support ticket.

When the real outage arrives — and it will — the page converts what would have been fifteen inbound “is it down?” calls into fifteen quiet refreshes. That’s the entire business case, and it’s plenty.

Status pages are available on every HITS Scout plan, including free — hitsscout.link/signup. Set up a monitor, curate the page, put the link in your footer, and forget about it until the day it earns its keep.

Next in this series: multi-region monitoring agents and the cross-monitor activity timeline — catching the incidents that only show up in one region, and the ones that hit three sites at once.

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.