Your personal OS needs a status page

Every SaaS product has one. A page that lists the components of the system — the API, the database, the notification service — and next to each one, a green dot or a red one.

You probably check yours when something breaks. You go to status.something.com and you find out the outage started four hours ago. That’s not the point of a status page. The point is that someone, somewhere, knows the state of the system at all times — not just when a user complains.

Your personal operation is a system. It has components. Most people find out those components are broken when they needed them.

That’s the wrong way round.

What a personal status page shows you

Not just automations. Not just tokens.

The full picture: what’s scheduled and when, what’s pending a decision from you, what integrations are live, what tasks have been handed off and haven’t come back, what your calendar looks like for the next 48 hours.

The shape of the thing is simple. Every morning, before you’ve made a single decision, you get a message that tells you the state of your system. Not an inbox — an overview. The inbox is the problem. The status page is the answer to the inbox.

Where an inbox shows you what others need from you, a status page shows you the state of the world as you’ve arranged it. The difference matters. One is reactive by design. The other is a choice.

Why most people don’t have one

It’s not that the idea is complicated. It’s that building it requires you to first decide what “the state of your system” means.

Most people haven’t made that decision explicitly. They have a vague sense of what’s outstanding. They hold it in their heads, imprecisely, expending low-level attention all day just keeping the queue from completely disappearing. The moment you have to articulate the components — what do I actually need to track? — you’ve already done most of the work.

The status page forces the question. That’s not a cost. That’s the value.

The components worth tracking

Start with what would cost you the most if it failed silently.

For integrations: the things that run without you but stop working without warning. OAuth tokens, browser sessions, Telegram connections, API keys with expiry dates. These go in the health check — a test, not just a presence check. Make the actual call. Confirm the actual output. Report pass or fail.

For tasks: anything handed off to a human that hasn’t come back. If your EA has three open items and you haven’t heard in two days, the status page surfaces it. Not because you’re managing, but because the system tracks what’s pending so you don’t have to.

For schedule: the next 24 hours. Not a full calendar view — just what actually requires your attention. A flight. A call you need to prep for. A hard deadline.

For decisions: anything where you’re the blocker. These are the most expensive items to let slip. The status page makes them visible before they become urgent.

What it looks like in practice

A Telegram message, every morning at 7 AM. Four sections, plain text. Fifteen seconds to read.

The integrations section is generated by a health check script — each one makes a real API call, confirms a real response. The tasks section pulls from a markdown file where handed-off items are logged. The schedule section hits the calendar. The decisions section is maintained manually — Claude updates it when something gets handed off or resolved.

The whole thing runs automatically. Some parts update in real time. Most update overnight.

By the time I open my laptop, I know whether anything needs fixing before I start work. I know what’s pending from my EA and what’s coming up in the next day. I know which integrations are healthy and which need attention.

That knowledge used to live in my head, imprecisely, consuming attention I didn’t notice spending.

The unexpected part

Building the status page forces a precision that improves the underlying system.

When you decide what to track, you discover things you’ve been managing loosely. An automation you thought was running that you’ve never tested since you set it up. A task you handed off six weeks ago that you stopped following up on because you forgot it existed. A calendar event you’re unprepared for because you never set a prep reminder.

The status page doesn’t just tell you the state of the system. It tells you which parts of the system you’ve never actually designed.

How to start

Pick one section. The health check is the easiest to start with because it’s bounded and testable. Take the integration that has failed most unpredictably and write a test that makes the real call and confirms the real output.

Get that delivering to wherever you already read in the morning — a Telegram message, a Slack message, whatever your morning channel is. Don’t build a separate system. Attach it to something you already check.

Once one section exists, the others follow naturally. The pattern is the same: decide what you want to know, write the thing that finds it out, route it to the morning message.

The goal is not a dashboard. A dashboard lives somewhere you have to go. The status page comes to you, every morning, before you’ve made a decision, so you start the day already knowing.

That’s a different way to operate.