Every RAXXO tool gets a public status page before it gets a marketing page
Five states cover every tool: operational, degraded, maintenance, incident, retired
The page exists to answer one question fast, not to explain what broke
Checking it every morning is the only thing that keeps it honest
Why the Order Is Backwards on Purpose
Most product checklists put the landing page first. Write the pitch, ship the hero image, get the buy button live, then worry about what happens when something breaks. I build in the opposite order. Before a RAXXO tool has a single line of marketing copy, it has a status page.
The reasoning is simple once you say it out loud. A landing page is a promise. A status page is what happens when the promise gets tested. If I only build the promise, the first outage becomes the first time a customer learns whether I take reliability seriously, and they learn it during the worst possible moment, mid-task, with no warning and no explanation.
Running five tools alone means I cannot answer every support message the second something goes wrong. I am usually mid-fix when the first "is this down for everyone or just me" message arrives. A status page answers that question before the customer has to ask it, which buys me the time to actually fix the problem instead of narrating it in real time to five different inboxes.
It also changes how I think about the tool itself while I am still building it. If I know a status page has to describe what "degraded" looks like for this specific product, I am forced to define degraded before launch, not during the first incident when I am under pressure and inventing definitions on the spot. Git Dojo failing to save a lesson is a different severity than Git Dojo running one second slower than usual, and I want that distinction written down somewhere calm, not decided live while a queue of confused messages stacks up.
There is a trust dimension too, one that matters more for a one-person studio than a bigger company. A team can lean on its name. I cannot. Every one of my tools has to earn trust on its own, one interaction at a time, and a status page is one of the cheapest ways to signal that I am not going to disappear when something fails. It says: I already thought about the day this breaks, here is where you will find out, and here is what happens next. That single page does more for confidence than another paragraph of feature copy ever will.
Building it first also means it ships with the product, not after the first embarrassing outage forces the issue. I have watched too many small tools treat a status page as a reaction to a bad week. By then it reads as damage control. Built ahead of time, it reads as a policy.
The Five States, and Why I Stopped at Five
Every RAXXO status page uses the same five states, in the same order, across all five tools. I resisted the urge to make each tool's page bespoke, because a status page that customers have to relearn per product defeats its own purpose.
Operational is the default and should be the boring, unremarkable state ninety-plus percent of the time. If a page spends most of its life anywhere else, that is not a status page problem, that is a product problem.
Degraded means the tool works but something about the experience is worse than normal: slower responses, a feature temporarily unavailable, a queue running long. Degraded is the state I use most carefully, because it is the one most tempting to skip. It is easier to say nothing and hope nobody notices a slowdown. But customers notice slowdowns whether I acknowledge them or not, and acknowledging one costs far less trust than staying silent through it.
Maintenance is scheduled and self-inflicted: a planned deploy, a database migration, anything I control the timing of. Maintenance windows get posted ahead of time when I can manage it, because a maintenance window nobody saw coming just looks like an outage with better PR.
Incident is the state nobody wants but every tool eventually hits: something is broken and I did not choose the timing. Incidents get a timestamp, a plain description of what is affected, and updates as the picture changes, not a single post-mortem after the fact.
Retired exists because tools do not last forever here. When a product reaches the end of its life, the status page becomes the permanent record: what it was, when it stopped, and what existing customers should expect. That state connects directly to the checklist every RAXXO tool goes through before I retire it, which spells out the exact sequence a product follows on its way out. The status page is where that sequence becomes visible to the outside world instead of staying a private decision.
Five states, always the same five, always in the same order. Anyone who has read one RAXXO status page already knows how to read all of them.
What the Status Page Deliberately Leaves Out
A status page is not a diary and it is not a confessional. It answers "is this working right now," not "why did this happen" in forensic detail, and definitely not "how does this system actually work under the hood."
I do not publish root causes in real time. During an incident, guessing at a cause and publishing the guess is worse than saying nothing, because a wrong guess gets treated as fact and then has to be walked back, which costs more trust than the original incident. The page states what is affected and what is being done about it. A short retrospective can come later, after the actual cause is confirmed, not while I am still finding it.
I do not put timelines I cannot promise on the page. "Fixed within the hour" is a sentence that sounds reassuring and becomes a liability the moment it is wrong. I would rather post "investigating, next update in thirty minutes" and hit that smaller promise reliably than make a bigger promise I might miss.
I do not use the status page to explain internal architecture, which service talks to which, what the deploy pipeline looks like, any of it. That information helps nobody who is checking whether their tool works, and publishing it just hands out a map to anyone looking for one. The page describes customer-facing impact only: what you can and cannot do right now.
And I do not let the status page become a place to relitigate a decision customers disagree with. If I remove a feature, that gets its own explanation elsewhere, connected to the reasoning behind the feature request I say no to every time. The status page is not the venue for defending product choices. It is the venue for one question only: is it working.
Keeping the page that narrow is what keeps it fast to write during an actual incident. I am not composing a careful explanation under pressure, I am filling in a template I already agreed with myself on months of calm days, not the day something is on fire.
The Habit That Actually Keeps It Honest
None of this matters if the page goes stale. A status page that still says "operational" during an active incident is worse than no status page at all, because it actively misleads instead of just staying silent.
The only thing that keeps mine accurate is a habit, not a monitoring dashboard with alerts I might sleep through. Checking every tool's real state is part of the same morning pass described in the error log I read every morning before anything else. If the log shows a spike, the status page gets updated before I do anything else, including before I start actually debugging. Customers waiting on an honest answer come before me chasing the fix, even though the instinct is always to fix first and explain later.
That ordering feels backwards the first few times. The bug is right there, I can see it, fixing it feels more productive than writing a sentence on a status page. But a customer staring at a broken tool with no acknowledgment starts assuming the worst: abandoned product, no one home, nobody coming. A customer staring at the same broken tool with a status page that says "investigating, degraded, next update in twenty minutes" assumes something completely different: someone is here, and I am one of five things they are personally handling right now, not a company hiding behind a support queue.
The habit also catches the state I am most tempted to skip: degraded. It is invisible unless I go looking, and going looking is exactly what the morning pass forces. A tool that is technically up but noticeably slower does not trigger anything dramatic. It just sits there until a customer messages about it, and by then the honest window already closed.
Five tools, one page each, checked in the same pass every single day. It is a small habit that does a large amount of the actual reliability work, more than any individual fix ever does on its own.
Bottom Line
A status page before a landing page sounds like the wrong order until you run five products alone and realize the landing page only has to be right once, at launch, while the status page has to be right every single day after. Building it first forces me to define what "working" and "not working" mean for a product before I am ever under pressure to decide in the moment.
The five states stay identical across every tool on purpose, so nobody has to relearn the page each time. What the page leaves out matters as much as what it includes: no guessed causes, no promises I cannot keep, no architecture diagrams, no relitigating product decisions. It answers one question and stops.
None of that holds without the habit of actually checking it, the same morning pass that already covers the error log, before anything else gets my attention. A status page nobody updates is just a landing page for bad news. Kept honest daily, it is the cheapest trust a small studio can build.
Top comments (0)