Posts

Posted on

Universal USB-C docks won the desk — and made you the QA team

Every few months someone writes a eulogy for the old click-in laptop docks, and How-To Geek’s recent piece is a good one: the proprietary dock that swallowed your whole laptop, charged it with a supply actually designed for it, and never once asked whether the cable was certified. It’s nostalgia with a point. But if you run desks for a small business or a homelab bench — and I do — the real lesson isn’t “old docks were nicer.” It’s this: universal docks didn’t eliminate the integration work, they transferred it to you.

What the old docks actually got right

The genuine advantages weren’t sentimental. A model-specific dock was sold as a tested appliance: the power supply was matched to the machine, the connector had enough parallel pins that peripherals weren’t fighting over one shared pipe, and the mechanical dock held the laptop like it was designed to — because it was. You plugged in and everything worked at full speed, every time, because the vendor had already done the compatibility testing on exactly one combination of hardware.

Why universal docks won anyway

None of that survives contact with reality, of course. Proprietary docks only made sense when a company bought one laptop model for everyone, and they died the moment laptops started outliving their dock generations. A single USB-C cable that drives two monitors, gigabit (or better) ethernet, audio, and charging on literally any modern laptop is a straight-up better deal for procurement. When the laptop fleet turns over and the docks stay, that’s money saved and e-waste avoided. Universal won on merit.

The catch: you’re the certification lab now

What disappeared was the tested part. USB-C’s famous mess means one connector shape hides half a dozen different capability levels. Take a random dock, a random cable, and a random laptop, and you genuinely cannot know what you’ll get — display bandwidth, charging speed, whether the 2.5GbE port runs at 2.5 or negotiates down — without checking spec sheets, and sometimes without benchmarking. The old vendor QA became a lottery, and the house always wins: you pay in flaky monitors, slow charging, and support tickets that say “the network is slow” when it’s actually a dock port.

So run it like infrastructure

Here’s the playbook I use. It’s less “throw out the universal dock” and more “do the QA the vendor stopped doing, once, properly.”

  • Standardize one dock SKU and one cable SKU. Not “whatever was cheap on the day” — one certified Thunderbolt 4 or USB4 dock, bought in multiples. Buy a spare before you need it, because the replacement in two years will be a different compatibility gamble.
  • Match the power budget to peak draw, not the sticker. If the laptop pulls 100W under load and the dock passes through 90, you’ll spend months blaming “battery problems.” Check the wattage at full tilt, not idle.
  • Keep the heavy lifting off the dock where you can. All those ports share one uplink. Displays, the wired NIC, and an external SSD streaming backups can gang up in ugly ways. On the homelab bench, anything that moves real data gets a direct port or its own NIC; the dock earns its keep on monitors, keyboard, and charging.
  • Burn in every new laptop-plus-dock combo once. Displays at target resolution and refresh, a sustained load while charging, and an iperf3 run through the dock’s ethernet port:

iperf3 -c 192.168.1.10 -t 30

Thirty seconds of that tells you more than any spec sheet. Do it on day one, not the day the new hire can’t figure out why their second monitor is 30Hz.

  • Purge the cable drawer. Mystery USB-C cables are where dock setups go to die. Keep the certified ones, label them, and recycle the rest — the cost of debugging one bad cable exceeds the cost of every good cable you own.

Verdict

The How-To Geek piece is right that something was lost: the old dock was an appliance, and appliances are lovely. But I wouldn’t go back, and for a small business you probably can’t afford to. The modern dock isn’t an appliance — it’s infrastructure, and infrastructure that nobody manages is just an outage with a delay timer. Pick one model, buy the good cable, run the burn-in once, and the “universal” dock gets you 95% of the old certainty with none of the lock-in.

Posted on

The ChatGPT desktop app makes a surprisingly good frontend for your local LLMs

The weak link in local LLMs has never been the models — it’s the frontends. Ollama and vLLM run beautifully on homelab hardware, but the chat UIs range from serviceable to science project. Which is why an XDA piece this month caught my attention: the author has been running local models — Qwen, GLM-Flash — inside the ChatGPT desktop app, with OpenAI’s client none the wiser, using a free open-source proxy called opencodex. That’s a trick worth understanding even if you never run it.

A proxy, not a fork — and that’s the clever part

opencodex works because the ChatGPT desktop app’s coding side reads its API endpoint from a local config file. The tool edits ~/.codex/config.toml and points it at itself:

# Auto-injected by opencodex
openai_base_url = "http://127.0.0.1:10100/v1"

From then on, every request — listing models, sending a chat — hits the local proxy first. It aggregates your configured providers into one model list, so your local models appear in the official model picker alongside the real OpenAI ones, prefixed by backend (a vLLM-served model shows up as vllm/glm-5.3-flash, say). When you pick one and send a message, the proxy routes the request wherever it actually needs to go.

The reason this is implemented as a proxy rather than a patched app matters: app updates keep landing and the integration keeps working. It survives upgrades because it never touched the app binary, only the config it reads. Anyone who’s maintained a fork of anything will recognize how much grief that design decision saves.

Setup is genuinely short

It’s an npm install. Run ocx init for a guided setup that writes the config and offers to inject the base URL into the config file. Out of the box it auto-detects the three runtimes most homelab people already run on their default ports — Ollama, vLLM, and LM Studio — and anything speaking an OpenAI-compatible API or Anthropic’s Messages API can be added manually. There’s a web dashboard for wiring up providers and, usefully for anyone who bills or budgets by tokens, per-model usage and cost statistics.

The homelab version of this

The interesting move for us isn’t laptop-local models — it’s that the proxy doesn’t care where the provider lives. XDA routes to models on multiple machines over a private network, which maps exactly onto how a homelab wants to run: vLLM serving something big on the GPU box in the rack, a smaller model on the workstation, all surfaced as one model list in a polished desktop client on whatever machine you’re actually sitting at. The frontend problem solves itself, and your model-serving architecture stays exactly as distributed as it already was.

Two honest caveats

Before you point a paying client at this, know where the seams are.

Tool-calling is the real compatibility test. The app’s agent tooling uses its own calling conventions — freeform patch edits, shell access, namespaced tools — and models trained on different conventions can flounder badly. In the XDA testing, one model got completely lost while others handled it fine. The fix is empirical: test your model on the tasks you actually do before trusting it, and don’t conclude “local models are broken” when it’s really “this model wasn’t trained for this client’s dialect.”

Not every request stays local. This is the one that matters for the privacy-motivated. The built-in web search tool still executes through OpenAI’s servers under your ChatGPT login, and if your local model is text-only, image requests get described by an OpenAI model first, with the text handed back to your model. Plain chat and code stay on your wire; search and vision do not. If your rule is “nothing leaves the house,” either avoid those features or accept exactly which calls bypass the proxy — because they will.

Verdict

opencodex is the missing piece a lot of local-LLM setups have been waiting for: a first-party-quality client pointed at your own hardware, with a design (config-level proxying) that won’t fall over on every update. Test your model’s tool-calling, keep an eye on which features phone home, and the best chat frontend for your homelab models might just be one you already have installed.

Posted on

The pocket network repair kit: what’s on my troubleshooting USB stick

Cloud storage killed the USB stick for most people, but there’s one flavour of thumb drive that deserves a revival: the pocket repair kit. An XDA piece recently made this case with four Windows-friendly picks, and it’s the right idea — it’s just aimed a bit too consumer for the homelab and small-business crowds. When a client site is half-down or your own rack is misbehaving, you don’t want to be downloading tools on the one connection you don’t trust. Here’s my version: what’s on the stick, and — the part everyone forgets — what’s in the pocket with it.

Carry it all with Ventoy

First, the container. The stick runs Ventoy, so it’s simultaneously a portable-apps drive and a multiboot installer: drop rescue ISOs (GParted Live, a Linux rescue image, memtest) next to the tools folders and boot any of them without re-flashing. One stick, every job. A 64GB drive is plenty; bigger just invites hoarding.

The software kit

Two of XDA’s picks make my cut unchanged, and I swap the rest for tools that answer the questions clients actually ask.

Wireshark Portable

Still the definitive answer to “what is this thing actually doing?” The classic move when a link feels slow: capture for sixty seconds, sort by bytes, and watch the backup job, the misbehaving smart TV, or the sync-happy app reveal itself. Portable runs without installing, which matters when you’re working on someone else’s machine and don’t want to leave footprints.

Nmap

The “is it even on the network?” tool. Two commands cover ninety percent of site visits:

nmap -sn 192.168.1.0/24

lists everything alive on the subnet — perfect for finding the smart plug that silently dropped off Wi-Fi — and

nmap -sV --top-ports 100 192.168.1.10

tells you what a mystery box is running and whether that IoT gadget is exposing more than it should. Before you pat yourself on the back for the closed ports, scan from outside too: the view from the LAN and the view from the internet are different audits.

iperf3

This is my first addition, and honestly the highest-value one. Clients don’t call saying “my TCP window scaling is suboptimal” — they say “it’s slow.” iperf3 splits that complaint in half in under a minute: run a server on the laptop, point the client at it from another device, and you learn whether the network is slow or the endpoint is. Wi-Fi that negotiates at 40Mbps, a flaky patch lead capping a gigabit run at 100 — iperf3 finds these while everyone’s still describing symptoms. Carry builds for Windows, macOS, and Linux; you’ll need all three.

mtr

Ping tells you a thing is down; mtr tells you where. It combines traceroute with continuous ping statistics, so instead of a single frozen path you get per-hop loss and latency over time. When the question is “us, the ISP, or them,” mtr answers it with evidence you can paste into a ticket. Run it for a few hundred cycles, not five.

dig

The XDA article suggests DNS Jumper for flipping between resolvers. It’s fine for consumer use, but dig gets you the truth without a GUI: query a specific server directly, chase the delegation chain, compare answers.

dig @1.1.1.1 example.com +trace

When “the internet is down” turns out to be one broken DNS record, this is the tool that finds it. It ships with BIND tools on Windows and everywhere else on Linux — no third-party download needed.

Where I differ from the original list

NetResView, the fourth pick, is a genuine throwback — SMB network browsing has been deprecated by Microsoft itself, and modern shares don’t announce themselves that way. If you need to inventory Windows shares and printers, nmap’s SMB scripts do it on any platform. A repair kit should be tools you trust on any box, not Windows XP-era utilities that half-work.

The hardware that rides in the same pocket

  • A USB 3.0 ethernet adapter. Instant second NIC for laptop captures, and a known-good spare when a desktop’s onboard port is the suspect.
  • A USB-serial console cable. The difference between a two-minute switch recovery and a drive to site. If you run any gear with a console port, this is non-negotiable.
  • Two known-good patch leads and a coupler. Half of “the network is broken” is one bad lead in a wall of good ones. Yours are known-good because they’ve never left the bag.
  • A phone with tethering. To download the driver you inevitably need, from a network that isn’t the patient.

Keep it honest

A repair kit rots quietly. Put a recurring calendar reminder to refresh it quarterly: update the tools, swap in current ISOs, and keep a plain-text manifest of what’s aboard. The worst time to discover your stick’s Wireshark is three years old is mid-outage, on a client’s machine, with no working internet.

Verdict

The XDA premise is right and the execution just needs a homelab accent: Ventoy for the container, Wireshark and Nmap as agreed, then iperf3, mtr, and dig — plus the physical bits that turn software into an actual repair kit. Old USB drives are free; a kit that saves one site visit pays for itself the first time you plug it in.

Posted on

Real wall-mounted touch screens for Home Assistant, without buying a tablet

Every home automation enthusiast hits the same wall: the phone is in the other room, nobody else wants to install the app, and a wall-mounted tablet costs real money for a job that’s mostly “turn off the lights.” Tessera (formerly ESP Screens) takes a swing at that wall with small ESP32 touch panels — from a 2.8-inch CYD board to a 10.1-inch Guition — running firmware you flash once and then manage entirely from Home Assistant. No YAML. No MQTT. No tokens. I’ve been watching this category for a while, and this is the first approach that feels like it was designed by someone who actually lives with other people.

The problem it solves

The standard answers to “always-available home control” are all wrong in some way. A wall tablet is expensive, overpowered, needs a mount and a permanent power scheme, and half the time you end up babysitting its battery or its updates. A phone app is one unlock-gesture away from nothing. Cheap e-ink buttons handle exactly one thing. What most rooms actually need is a small, dumb, always-on surface with a handful of tiles: lights, heating, maybe the vacuum. That’s the whole spec, and Tessera nails it.

How it works

The project is two halves. The firmware side runs on the panel itself. The Home Assistant side is an app called ESP Screen Manager, which handles everything else: it flashes a new screen over USB, updates it over Wi-Fi afterwards, and pushes your tile layout to it. Layout is done in a drag-and-drop editor — pick a tile, drag it, hit Save & send. Changing a screen doesn’t mean reflashing it, and there’s no blueprint to wrangle.

Five panels are supported today: the 2.8-inch CYD, a 4-inch and a 10.1-inch Guition, and 4.3-inch and 7-inch Waveshare boards. The firmware measures its own canvas at boot and lays out pages to fit — around six tiles on the little CYD, twenty on the big Guition — while tiles stay roughly the same physical size in millimetres. The same home scales across all five glasses, which is a smart touch if you standardise on the ecosystem and then upgrade a room later.

What the tiles can do

  • Lights, climate, blinds and curtains, the vacuum, and media controls
  • Weather, clocks, timers, and history graphs
  • Your alarm with a proper keypad, plus cameras on every screen except the 2.8-inch CYD
  • A tile that fills a whole page as one big switch you can hit without looking, and tiles that navigate to another page

The detail that sold me: an automation can push an alert to every screen in the house at once. Someone rings the bell, every panel lights up, and any screen with room for a picture shows who’s standing there from the doorbell camera. That’s the difference between a control panel and something that genuinely earns wall space.

Brightness, night hours, and dark mode can all be driven by automations, and if you do hand-write YAML for one screen, it survives firmware updates. Little things, but they’re the little things that decide whether a family actually uses the panels or learns to ignore them.

My buying advice

Start with one mid-size panel — the 4.3-inch Waveshare or the 4-inch Guition — in the room where the “phone in the other room” problem bites hardest. Don’t begin with the 2.8-inch CYD: it’s the cheapest entry point and a fun toy, but six tiles is tight and no camera feed is a real limitation. The 10.1-inch Guition is the living-room showpiece; earn your way to it.

The honest caveats

These are ESP32 panels, not iPads. The screens are modest, the touch is functional, and you shouldn’t expect to mirror a full Home Assistant dashboard on them — this is deliberately a tiles-and-pages model, not a mini browser. It’s also very much a community project with a solo developer and a donation link: pin the version you install, expect the occasional rough edge, and maybe throw the author a coffee if it earns a spot on your wall.

Verdict

A tablet on the wall is a general-purpose computer doing a single-purpose job badly. Tessera flips that: single-purpose hardware doing a single-purpose job properly, at a fraction of the price, with an editor simple enough that non-technical household members won’t need you to change anything. For small-business fitouts — a reception panel for the alarm, a workshop panel for the roller door — the same logic applies double. This is how wall controls should have worked all along.

Posted on

God’s Eye View: a live 3D globe of public data you can run on your own machine

Most of the dashboards we build in this hobby stare inward. Grafana graphs the temperature of a rack, Uptime Kuma watches our own URLs, the odd ESP32 sensor feeds a gauge nobody outside the house will ever see. Every now and then, though, a project comes along that points all that homelab energy at the outside world. God’s Eye View is that project: a photorealistic 3D globe in your browser that renders live public data — aircraft, ships, satellites, earthquakes, weather, even public cameras — and, refreshingly for something this impressive, runs locally with source code you can actually read.

What it actually is

Built by Bilawal Sidhu (of the God’s Eye View YouTube series), the project describes itself as “a spy satellite simulator in your browser, except the data is real.” That’s accurate. The globe layers a stack of open signals onto one explorable earth:

  • Live aircraft from flight transponders (ADS-B), with a cockpit view that can ride a tracked flight down to the ground
  • Ship beacons (AIS), orbital elements for satellites, and seismograph feeds
  • Weather on a scrub-able timeline: forecast winds, observed radar, satellite clouds, lightning, cyclone tracks — no API key needed
  • Public camera locations mapped from OpenStreetMap, including tagged license-plate-reader sites
  • Simulated traffic flowing along real roads, aggregated from location data

You can click-to-track anything, speak annotations onto the map as real polygons, reskin the whole thing with GLSL sensor looks (CRT, night vision, thermal), and serialise your exact view — camera, layers, even a live-tracked aircraft — into a shareable URL. It hit #1 on GitHub Trending in August 2026, and it earned it.

Why a homelab person should care

Two reasons. First, it’s the Grafana mindset applied to the planet. The skills that make you good at dashboards — choosing the right data source, filtering noise, composing a view that answers a question — are exactly the skills this thing rewards. Each data layer is a separate module, so extending it with your own feed (your station’s seismograph, your ADS-B receiver’s coverage, your farm’s soil moisture) is the obvious next step once you’ve played with it.

Second, it starts without API keys and runs locally. You install it via Pinokio in one click or clone it and run it from the terminal, and the base experience just works in your browser. Optional keys unlock extras inside the app when you want them. For a box that lives on your LAN serving a household, that’s the right default: no telemetry to a third party, no account to create, nothing phoning home that you didn’t configure.

Practical uses beyond the pretty factor

I’ll be honest: most evenings it’s a toy, and a very good one. But it has quietly useful moments:

  • Satellite passes: ask by voice when a loaded satellite next rises over you, and get rise, peak, and set times with a yes/no on visibility. Handy before a planned pass or an ISS photo attempt.
  • Weather events: replaying observed radar alongside cyclone tracks during a storm front is more informative than a static news map, and the timeline scrubbing makes the structure of a system obvious.
  • Analyst queries: counting, filtering, and ranking things by voice — flights, ships, fires, quakes — with staleness flags on the answers. It’s a surprisingly decent situational-awareness terminal when something is happening somewhere.

Honest caveats

The README is admirably upfront about what’s real and what isn’t, and you should hold that line too: traffic is simulated along real roads, and camera positions and rocket trajectories are coarse estimates. If you find yourself treating it as ground truth during an actual emergency, you’ve drifted. It’s open-source spatial intelligence, not an emergency service.

Also note the voice agent means a microphone. Running locally is the right call, but if you’re the sort who tapes over laptop cameras, think about where this one runs and who’s near it.

Worth your disk space

Projects like this usually end up as a viral video and a dead repo. This one has the opposite shape: real engineering, modular layers, a local-first install, and documentation that admits its own fudges. Drop it on the homelab box, hand the globe to whoever wanders past, and see how long it takes before someone asks “wait, can we put our own data on it?” That question — not the globe — is the actual product.

Posted on

Introducing ExploreDNS: DNS debugging that walks every branch, not just the first answer

Every DNS debugging session starts the same way: you run dig, you get an answer, you move on. The problem is that dig tells you what one resolver saw on one path at one moment in time. The domain name system is a tree — thirteen root server identities, a handful of TLD servers, however many nameservers you’ve delegated to — and a normal lookup walks exactly one branch of that tree and stops at the first answer that works.

That’s usually fine. It’s exactly not fine when you’ve just moved nameservers, or one of your authoritative servers is misbehaving, or a referral is quietly broken in a way that only matters the day something else also fails. The working branch hides the broken ones.

What ExploreDNS does

ExploreDNS is a free tool from Hansen IT Solutions that walks the entire delegation tree for a domain — the way a real iterative resolver would, but without the shortcuts. It starts at the root servers, follows every referral it receives, resolves nameserver addresses out-of-band when the glue records are missing, and keeps going until every branch is exhausted. Then it collates everything it saw into one report: a readable tree in the browser, or JSON if you’re piping it somewhere.

You can use it right now at exploredns.hansenits.com — no account, no cost, no “contact sales” button. There’s also a CLI and Docker images if you’d rather stay in a terminal, which I’ll get to.

The problems this actually catches

When you can see every path through the delegation instead of one lucky path, a whole class of DNS problems stop being mysterious:

  • You’ve moved nameservers. Are the root and TLD servers pointing every path at the new delegation, or is your laptop’s cached resolver just telling you what you want to hear? Each branch shows what the public hierarchy actually serves, not what your cache remembers.
  • Authoritative servers disagreeing. If one secondary is still serving the old zone, a single lookup might hit the healthy one and look fine. Side-by-side branch results surface the disagreement immediately.
  • Missing or stale glue. When a referral names nameservers whose addresses aren’t shipped in the parent zone, ExploreDNS resolves them out-of-band and shows you the gap — before a resolver somewhere else fails to.
  • CNAME spaghetti. It follows CNAME chains to the end and detects loops, which is exactly what you want when a migration has left a trail of aliases three services deep.
  • Transport weirdness. Answers that truncate over UDP, EDNS0 buffer sizes misbehaving, servers that only respond on TCP — you can force TCP for the whole traversal and compare.
  • Version fingerprinting. It queries version.bind (CHAOS class) along the way, so you get a picture of what software is actually answering on each branch — handy for audits and for finding that one NS nobody remembers patching.

All thirteen roots

A single traversal from one root server is still one view. Enable “all root servers” and ExploreDNS starts a traversal from every one of the thirteen root server sets, in parallel, and merges the results. Because the roots and TLD servers are the one piece of DNS infrastructure everyone genuinely shares, this is the closest thing to asking the public DNS hierarchy, collectively, “what do you actually think of this domain?” Inconsistent answers between roots almost always mean something interesting upstream — or a cache doing something it shouldn’t.

The web interface

The public instance streams traversal progress in real time — you watch the tree build branch by branch as queries complete, with a summary panel tracking results, answers, errors, maximum depth and duration. For big zones with deep delegations it’s oddly mesmerising, and more practically, you spot the red branches as they happen rather than parsing a wall of text afterwards.

For terminal people

ExploreDNS is written in Go and ships as a single static binary with no runtime dependencies, so it’s equally at home on your laptop or a jump box:

# MX records, all 13 root server sets, JSON output
exploredns --type MX --all-root-servers --json example.com | jq .

# Force TCP end-to-end (answers that only survive TCP show up fast)
exploredns --always-tcp example.com

Grab a prebuilt binary from the releases page, go install it directly, or use the published Docker images for the CLI and the web UI if you’d rather self-host the whole thing behind your own domain. Worth knowing: by default the tool runs in fast mode, sharing resolved nameserver addresses across branches for speed. Turn it off (--fast=false) when you want every branch to resolve independently — slower, but it exposes per-branch resolution failures that fast mode papers over.

A nod to where it came from

ExploreDNS is inspired by the classic dnstraverse Ruby tool, which did this dance years ago and then slowly faded as Ruby runtimes became something nobody wanted to install for one utility. This is a modern Go rewrite with the same stubborn idea at its core: don’t trust the first answer; walk the whole tree. It’s released under GPLv3, and the source is up on our Gitea if you want to see how the traversal works or run your own instance.

After DNS comes uptime

Getting every branch of your delegation answering correctly is step one. Knowing it stays that way is step two — if you haven’t already, have a look at HITS Scout, our uptime monitoring service that checks more than your homepage. DNS resolving everywhere, endpoints actually answering: it’s the same philosophy, one layer up.

Point your next DNS mystery at exploredns.hansenits.com and see what the whole tree thinks.

Posted on

HITS Scout plans and pricing: which tier actually fits

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.

Posted on

Multi-region monitoring and the activity timeline

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.

Posted on

Building a public status page for client sites

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.

Posted on

Wiring HITS Scout alerts into Discord and Slack

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.

WordPress Appliance - Powered by TurnKey Linux