The last two posts were about two questions a solo practice has to keep answering: is the site correct, and is the site open. Khai answers the first. The three watchers answer the second. But between them, and everything else that keeps a telehealth practice running, I had a new problem: too many places to look.
Each of those signals lived somewhere different. Khai's reports in one place, the site status in an email, the build alerts somewhere else, the payment watcher somewhere else again. And that's before you count the things I haven't written about yet: whether the backups ran, whether a certificate is about to expire, whether a service is bumping against a quota, whether the database is healthy. Every one of them had a home, and no two homes were the same, and the practical result of ten homes is that I checked none of them, because checking ten things is a chore and chores don't happen on busy days. This post is about the fix: one screen that shows me the whole operation at a glance.
Ten places to look is zero places checked
The monitoring from the last post solved the urgent half of the problem. When something breaks in a way that can't wait, an alert comes to me. That's the push, and it's essential. But push only covers the things you've decided are alarm-worthy, and it only fires on the transition from fine to broken. It doesn't answer the quieter question I also need answered, which is just: what's the state of everything right now. Not "did anything break," but "show me the whole board."
For a while my answer to "show me the whole board" was to go visit each tool in turn, and the problem with that is the same problem the monitoring already taught me. A thing you have to remember to check is a thing you'll check when you're worried and forget when you're not, and the whole board is exactly the thing you want to see when you're not yet worried, so you can catch the amber before it goes red. Ten places to look is zero places looked at. The only number of places that actually gets checked is one.
So I built the one place. A single dashboard that pulls the state of everything that matters into a screen I can take in without clicking anything, so that the answer to "is everything okay" is a glance and not an expedition.
What goes on the one screen
The dashboard aggregates the health of the whole operation, and the list of what counts as "the whole operation" is longer than you'd think for a practice run by one person.
Are the sites up. Did the recent deploys pass or fail. Are payments flowing. Did last night's backups actually run and land where they're supposed to. Are the SSL certificates comfortably far from expiring. Is any service creeping toward a usage limit that would cut it off. Is the database responsive and within its resources. Each of those is a question I used to answer by going somewhere specific, and each of them is now a tile on one screen, reporting its own status.
The design principle is that the screen should answer "is anything wrong" before it answers anything else. When I open it, the first thing I should get is a verdict, not a puzzle. If everything is green, I'm done, I close it, I go see patients. If something is amber or red, that's where my attention goes, and only then do I dig into the specifics. The dashboard's job is to make the common case, everything is fine, take one second, and to make the rare case, something needs me, impossible to miss.
The four that earn their keep
A few of these do more work than the rest, and they're the ones I'd build first if I were starting over. Two are the checks I most rely on to know things are healthy, and two are less about health and more about running the day, the screens I actually work from. All four are the difference between running the practice and hoping it's running.
The first is the integrations: the third-party services the practice is built on, each of which can quietly stop working in a way that doesn't surface until a patient hits it. The electronic health record and prescribing system, the payment processor, the AI models, the email and text providers, the maps and reviews APIs, the video-visit service. Each is a dependency, and the check that matters is not "is the vendor up" but "can this integration actually do its job for me right now." For the token-based ones, that means confirming the login token is valid and still refreshing, because the classic silent failure is a token that quietly expired days ago, so charts and prescriptions stop flowing and nothing says a word until I go looking. For the metered ones, it means confirming I'm authenticated and under quota, because an API that's connected but over its limit is just a slower way to be disconnected.
The second is revenue, and it's the tile I probably open most, because it's where I actually look at the money. Not just "are payments succeeding" as a health light, though it's that too, but the question a practice owner asks a dozen times a week: what's coming in. Recent charges, the trend, how this week compares to the last. And because the answer to a revenue question is so often one specific transaction, this is also where I issue refunds, right there, without logging into a separate payments console. When a patient needs money back, the place I see it and the place I handle it are the same place, which is the whole point of a cockpit: notice it and act on it without changing screens.
The third is communications, and it's my single most-used lookup, because it answers a question that comes up constantly: what did we actually send this patient. A practice sends a startling number of messages, appointment reminders, treatment letters, magic-link logins, follow-ups, replies to texts, across both email and SMS, and most of them go out automatically, which is exactly why I need one place to see them. When a patient says they never got the reminder, or I want to confirm a letter actually went out, or I'm picking up a text thread from three days ago, this is where I go: a single per-patient history of every message we've sent them, email and text together, in order. It turns "did we send that" from a guess into a fact, and "what did we say" from memory into a record.
The fourth is backups, the tile you never think about until the one day it's the only tile that matters. It confirms that last night's database backup actually ran, that the snapshot exists, and that it copied to a separate account the main one can't touch, so a mistake or a compromise on the primary side can't take the backups down with it. The distinction it's built around is the one people get wrong: "a backup job is configured" and "a restorable backup exists as of this morning" are different claims, and only the second one saves you. So the check confirms the second. A backup you haven't confirmed is not a backup, it's a hope.
Red, amber, green
The hard part of a dashboard is not gathering the data. Gathering the data is the easy part, and it's the part most dashboards stop at, which is why most dashboards are useless. The hard part is turning the data into a verdict.
A screen full of raw numbers is not a dashboard, it's a spreadsheet, and a spreadsheet is another thing to interpret at exactly the moment you have no attention to spare. Every raw metric on a status screen is a small tax on the reader, a little bit of "is that number good or bad" that adds up until the whole thing is too expensive to actually look at. So the discipline is that every check has to resolve to a state, not a statistic. Green, amber, red. Fine, worth a look, deal with this now. The judgment about whether a number is good or bad gets made once, in the code, by me, when I'm calm, rather than every morning, by me, when I'm rushing.
This is more work to build than a wall of numbers, because it forces me to define, for every single check, what actually counts as okay. But that work is the entire value. A dashboard that makes me interpret is a dashboard I'll stop opening. A dashboard that hands me a verdict is one I'll open every day, and a dashboard you actually open is the only kind worth having.
The operational history
A dashboard shows you the present. The other half of the screen, and the half I underestimated at first, is memory: a running timeline of the significant things that have happened to the practice over time.
Every meaningful event gets logged to it. A new service launched. A piece of infrastructure changed. An incident, and then its recovery. A compliance milestone. A config change worth remembering. Individually none of these feels important enough to write down in the moment, which is exactly why you have to, because the value isn't in any single entry, it's in the timeline you can read six months later.
The reason this matters more for a solo operator than for a team is that a team has institutional memory distributed across people. Someone remembers why that setting is the way it is, someone remembers the outage last spring, someone remembers that we tried this before and it didn't work. I am the entire institution, and my memory is lossy in exactly the way everyone's is: I will not remember, in October, what I changed in April, and I will be certain that I do, which is worse. The operational history is the practice's memory made external and permanent, so it doesn't degrade at the speed mine does.
And it earns its keep at the worst possible moment. When something breaks, the first useful question is almost always "what changed recently," because most breaks are downstream of a change, and a timeline of recent changes turns that question from an archaeology project into a glance. The dashboard tells me the present is on fire. The history tells me what I did yesterday that might have lit it.
Push and pull, working together
It's worth being clear about how the dashboard relates to the monitoring from the last post, because they look like they overlap and they don't.
The monitoring is push. It reaches out and interrupts me when something crosses from fine to broken. The dashboard is pull. It sits there, and I reach for it when I want the whole picture, either as a habit or in the moment right after an alert fires, when the alert has told me one thing is wrong and I need to see the shape of everything else to understand it. Push answers "is something wrong right now, urgently." Pull answers "what is the state of everything," and "what has the state of everything been over time." A solo operation needs all three of those answers, and they come from these two tools working together: the watchers that interrupt, the board that summarizes, and the history that remembers.
The honest limitation
A dashboard is only ever as truthful as its checks, and a check that has quietly stopped testing the real thing is worse than no check at all, because a green light you trust is more dangerous than a question you know you haven't answered.
The failure mode is a tile that reports green by measuring a proxy instead of the real dependency. A check that pings a service's health endpoint and calls it good has confirmed that the service is running, not that the service can actually do its job, and those are different claims that a single green light quietly conflates. I've had a probe on this dashboard that was faithfully monitoring a path that could no longer even run, reporting reassuring green about a thing that was effectively dead, until I noticed and replaced it with a check that tested the real capability. That is the same lesson as the backup alert path from the last post, wearing different clothes: a safeguard that only looks connected is worse than a known gap, because a known gap gets your attention and a false green buys your trust. So the checks have to test the real dependency, and the ones that have stopped meaning anything have to be found and either fixed or deleted, because a dashboard slowly fills with comfortable lies if you let it.
Why this matters for a solo practice
One screen and one glance is how one person holds an operation with a dozen moving parts in their head, which is to say, how one person holds it without holding it in their head at all. The dashboard is the cockpit, the single place I look to fly the thing. The operational history is the flight recorder, the thing that lets me reconstruct what happened after the fact. Together they mean I don't have to remember the state of everything, or the story of everything, because both are written down somewhere I can look.
That's the real point of all of it. A solo practice doesn't fail because one person can't do the work. It fails because one person can't hold all of it in mind at once, and the mind is where things get dropped. Every tool in this series so far exists to move something out of my head and into a system that won't forget it on a bad day. The dashboard is where all of that comes together into a single view, so that being the only person watching is actually possible, because being the only person watching is a lot easier when you only have to look in one place.
Next time
The dashboard assumes someone is there to look at it. The next post is about what happens when that someone isn't: nights, weekends, the hours I'm asleep or with my family or simply away, and how a one-person practice handles the fact that the one person cannot be on call every hour of every day. Coverage, after-hours, and the honest limits of being a practice of one.