The last post was about whether the site is correct: whether the links work, whether the flows submit, whether a patient can get through the intake without hitting a wall. This one is about a different and more basic question, the one underneath that: is the practice even open right now. Because a site can be perfectly correct and still be closed for business, and if you're a solo operator, the closed sign can go up without anyone telling you.

In a physical office you know if you're open. The lights are on, the door's unlocked, someone's at the desk. A telehealth practice has none of those cues. The whole thing is a website and a set of services humming somewhere in a data center, and the difference between open and closed is invisible unless you go looking, or unless something tells you. The failure I most wanted to avoid is the one where a patient discovers the practice is closed before I do. This post is about the robots that make sure that doesn't happen.

The three ways you're closed without knowing

There are three distinct ways a telehealth practice can be closed while you're going about your day assuming it's open, and they're worth separating, because they fail differently and you catch them differently.

The first is the obvious one: the site is down. The server isn't responding, the page won't load, and anyone who tries to reach you gets an error or a spinner that never resolves. Closed.

The second is subtler: you shipped a change and the deploy failed. Maybe the build broke, maybe it half-deployed, maybe the site is now serving an error on a page that worked yesterday. You pushed the change and moved on, assuming it took, because it always takes. Except this time it didn't, and the practice has been quietly broken since the moment you thought you'd improved it.

The third is the sneakiest: the site is up, the pages load, everything looks fine, and payments are silently failing. A patient fills out the intake, goes to pay, and the charge doesn't go through, and they either try a couple of times and give up or they assume it worked and you never see them. The site is open. The register is broken. That's still closed for business, and it's the kind of closed that looks exactly like open from where you're standing.

Each of these can happen without a single thing landing in your inbox, unless you've built the thing that makes it land there. So I built three watchers, one for each.

Is the site up?

The first watcher answers the simplest question: are the sites responding. It checks them on a schedule and it tells me the answer, and the important design choice is that it tells me the answer whether or not anything is wrong.

That sounds redundant. If everything's fine, why send a message? Because "no message" is a terrible way to signal "everything's fine." If the only time you hear from your monitor is when something breaks, then silence is ambiguous: it might mean all is well, or it might mean the monitor itself is dead and can't tell you the building is on fire. So my site check reports in twice a day, morning and evening, with the status of everything, and the report arrives even when the report is boring. A boring report is the good outcome. And because it arrives on a schedule, the day it doesn't arrive is itself a signal.

The morning report is the one I actually rely on. It's the first thing that tells me the practice survived the night, that the sites are up, that nothing fell over while I was asleep. It's the telehealth equivalent of walking up to the office and seeing the lights already on. The evening one closes the loop before I stop paying attention for the day.

Did I just break the build?

The second watcher is about the moment right after I ship a change, which is statistically the most dangerous moment for the practice, because I am the thing most likely to break it.

When a solo operator is also the developer, most outages don't come from the data center having a bad day. They come from a change you made. You push something, the deploy runs, and either it works or it doesn't, and the failure mode I care about is the one where it doesn't and you don't notice, because you've already closed the laptop and gone to see patients. So this watcher is event-driven rather than scheduled: the moment a deploy finishes, it tells me whether it succeeded or failed. A failed build means the change I just made didn't ship, and depending on how it failed, it might mean the site is now serving an error where it used to serve a page.

The value here is entirely about timing. A broken deploy I hear about within a minute is a two-minute fix, because the change is fresh in my head and I can just roll it back or push the correction. The same broken deploy discovered three days later, by a patient, is a mess with a cold trail, because now I have to reconstruct what I even changed. The watcher collapses that gap. It turns "I wonder if that deployed okay" into a thing I don't have to wonder about, because I'll be told.

Are payments going through?

The third watcher is the one I'd have skipped if I hadn't thought hard about what "open" actually means, and it's the most important of the three.

A practice makes money one way, and if that one way silently stops working, you can go a surprisingly long time without noticing, because a failed payment is invisible from your side. Nobody emails to say "I tried to pay you and couldn't." They just don't become a patient. From where you sit, a broken checkout and a slow week look identical: fewer patients than usual, no obvious reason. You could stare at that for two weeks and conclude your marketing has gone soft when the truth is the register has been broken the whole time.

So the third watcher watches the payment events. When charges are going through, it's quiet. When something changes in a way that suggests payments are failing, it tells me, so that a broken checkout surfaces as an alert I can act on today rather than as a mysteriously bad month I diagnose too late. Of the three watchers, this is the one that most directly protects the practice, because the site being down is loud and obvious eventually, but the register being broken is quiet all the way to the empty bank statement.

Push, not pull

The thread running through all three is a single principle: the monitoring comes to me. I don't have to remember to go check a dashboard, because the whole problem with checking a dashboard is that you only remember to check it when you're already worried, and the entire point is to be told before you have a reason to worry.

There are two shapes this takes. The scheduled heartbeat, the twice-daily report, is for the slow questions where a few hours of latency is fine and the real job is confirming that all is well and that the monitor is alive to say so. The event-driven alert, the build and payment watchers, is for the fast questions where minutes matter and waiting for the next scheduled report would be waiting too long. Between them they cover both failure speeds: the sudden break that has to reach me now, and the slow drift that I need confirmed every day.

The reason this matters more for a solo operator than for a company is that a company has people whose job is to notice. Someone's watching the graphs, someone's on call, someone will see the spike. I have none of those someones. The monitoring is the someone. It's the on-call engineer, the ops team, and the person who notices the register's broken, and it has to be, because the alternative is that the someone who notices is a patient.

Who watches the watchers

Here's the honest problem with all of this, the one you have to stare at directly: a monitor is just more software, and more software can also fail, and when a monitor fails it usually fails silently, which is the worst way, because a silent monitor is indistinguishable from a healthy one that has nothing to report.

There are two defenses and I use both. The first is the heartbeat: because the site report is supposed to arrive twice a day, its absence is information. A monitor that only speaks up on bad news can die without you noticing, but a monitor that's supposed to check in on a schedule announces its own death by going quiet when it shouldn't. The second is redundancy for the alerts that actually matter: an alarm with only one way to reach you is an alarm with a single point of failure, and if that one path is having a bad day the alarm just doesn't ring. So the messages that can't afford to be missed should have more than one way to get to me. And the part that's easy to get wrong, the part I've learned to check, is that a backup path only counts if it actually works. A second channel that's wired up in theory but was never really connected is not redundancy, it's the comforting appearance of redundancy, which is worse than knowing you have none. Verifying that the backup actually fires is its own small discipline, and it's worth doing, because the day you need it is the worst possible day to find out it was never really there.

Why this matters for a solo practice

None of this is exotic. It's uptime monitoring, build alerts, and payment checks, the kind of thing any real operation has. The point of writing it down is that a solo telehealth practice is a real operation, with real patients depending on it being open, run by one person who also has to be the doctor, and that person cannot also be staring at a status page all day.

So the monitoring does the staring. The goal was never zero downtime, which is not something a one-person operation can promise. The goal is that I am always the first to know, so that by the time a patient is affected I'm already on it, or better, I've already fixed it and they never knew. Open or closed is a fact about the practice at every moment. The only question is whether I find out from a robot or from a patient, and I would very much rather it be the robot.

Next time

Three watchers is a good start, but three separate streams of alerts is also three more things to keep track of, and the next post is about pulling all of it, the site checks and the build alerts and the payment signals and everything from the last post too, into a single screen: the one dashboard that shows me the whole operation at a glance, so that "is everything okay" has one place to look instead of ten.