Every monitoring tool ships a dashboard. Most of them are good. Almost none of them get looked at.

Not because they're badly designed, but because a dashboard is a place you have to decide to go. It competes with the client email, the deploy that's half-finished, the invoice you meant to send. On the days when everything is fine, opening it teaches you nothing, so you stop. And then, on the one day it would have told you something, it's a bookmark you haven't clicked in three weeks.

This is worth naming, because the industry's answer to it has mostly been "we'll alert you," and alerts solve a narrower problem than people think.

What alerts are good at, and what they aren't

An alert is an interrupt. It's the right tool for a discrete event with a clear boundary: this monitor was up, now it's down, go look. For a hard outage on a site that matters, an alert is exactly what you want, and Sentinel will send you one.

But interrupts have two failure modes that anyone managing more than a handful of sites runs into.

The first is volume. Route enough monitors into one inbox or one Slack channel and the alerts stop reading as urgent. This is not a discipline problem. It's what happens to any signal that fires often enough to become background noise, and the usual fix (tightening thresholds until it goes quiet) trades false alarms for missed ones.

The second is subtler and gets less attention: an alert can only tell you about a state change. It cannot tell you that nothing has changed, and there is no notification for "everything has been fine for six days." That sounds like a non-problem until you consider what it means in practice. If your alerting is misconfigured, if a webhook silently 404s, if a monitor got paused during a migration and never got resumed, the experience is identical to everything working. Silence is the same shape as success, right up until it isn't.

For a freelancer or an agency, that's the uncomfortable one. You are not usually worried that you'll miss a page-down alert at 2pm on a Tuesday. You're worried that something is quietly wrong with the monitoring itself and you'd have no way to know.

Passive awareness is a different thing

The alternative isn't more alerts. It's making the current state visible somewhere you already look, so that checking costs nothing and happens by accident.

This is a well-worn idea outside our corner of software. A car's fuel gauge doesn't interrupt you; it sits in your field of view and you absorb it without deciding to. You don't "check" it so much as notice it. The alerting equivalent (a light that comes on at empty) is useful too, but the gauge is what stops you from getting there.

A menu bar is the closest thing a Mac has to that. It's persistent, it's already in your eyeline, and glancing at it doesn't require leaving what you're doing or forming an intention. The bar for "did I check on the client sites today" drops from open a browser, find the tab, log in, scan to look up.

The difference this makes isn't dramatic on any given day. It compounds. You notice a monitor is degraded while you're waiting for a build. You see the count of online sites drop from 28 to 27 and it registers before an alert would have. And crucially: on a normal day, you see a green count that confirms the monitoring itself is alive, which is the one thing alerting structurally cannot give you.

What this looks like for client work

If you're monitoring one site, this is a nice-to-have. The argument gets stronger with every client you add, for a specific reason: the failure you actually fear changes shape.

With one site, you fear the site going down. With twenty client sites, you fear not knowing which ones you're currently responsible for. Sites get added during onboarding and never removed at offboarding. A monitor gets paused for a migration. A domain moves and the old monitor keeps passing against a parked page. None of that generates an alert, because none of it is a state change your monitoring recognises as bad.

An always-visible count is a cheap check against all of it. If you know you have 28 client sites under contract and the menu bar says 25, that discrepancy surfaces on its own, without a report, an audit, or remembering to look.

A few things worth setting up alongside it, whatever tool you use:

Separate the signals that fail on their own schedule. SSL expiry and domain expiry don't degrade, they lapse, on a date decided months ago by a renewal cycle nobody diarised. They deserve their own tracking rather than being folded into uptime.

Watch for the job that didn't run. Heartbeat and cron monitoring is the clearest example of silence-as-failure. A missing check-in produces no error anywhere, which is precisely why it needs something expecting it.

Assert on the response, not just the status code. A monitored API can return 200 OK with an empty payload or a stale cache indefinitely. Checking for the value you expect catches what a reachability check waves through.

Give the aggregate a home you'll actually see. Whether that's a menu bar, a wall display, or a status page you keep open, the point is that the summed state lives somewhere passive rather than behind a login.

The honest constraints

Two, both worth saying plainly.

It's macOS only. There's no Windows or Linux build today, and if that's your machine, the browser dashboard and alerts are what you have.

And it needs a paid plan. The app is a free download, but it authenticates with an API token, and API access starts on the Starter tier. On the free plan you can install it and it won't connect, which is a genuinely annoying thing to discover after the fact, so: it's not available on free.

Where Sentinel fits

The Sentinel menu bar app shows the count of online, degraded, and offline monitors across every site you're watching, with native macOS notifications when one changes state and one-click access to any monitor's detail page. It refreshes on an interval you set, from 15 seconds up, and it reads through the same read-only API token you'd use for anything else, so it can't change anything in your account.

It isn't a replacement for alerting, and it isn't trying to be. Alerts handle the interrupt. The menu bar handles the other 99% of the time, when nothing is wrong and the only thing you need is to be able to confirm that cheaply.