We run on this

The fastest way to find out whether a tool is any good is to make the people who built it depend on it. That's what we do: MyStatus is how MyStatus gets built, and what follows is how we do that.

There is a version of this page that just says "we use our own product!" and moves on. This is not that page. Each thing below is something you can point at your own work, today, with the same public tasks and the same API everybody else gets. Where that takes a bit of setup, it says so.

The build log writes itself

Every piece of work here happens on its own branch, and the branch announces itself. When one opens, a row goes up. While it is open, a row goes up every half hour saying what is being worked on. When it merges, a row goes up with the result. Nobody types those; the workflow posts them as it goes.

The useful part is what that stream then supports. The stats page reads the newest row and turns it into a sign telling you whether anybody is currently coding. Since a crashed session cannot post "I stopped," the sign goes dark on silence rather than waiting to be told. Absence is the signal.

You can do this. A status stream that a machine writes to is a normal task with an API key pointed at it. What makes ours readable by a program is that it never parses prose: a row carries a label, a timestamp, and its links, and everything downstream reads those three fields.

The half that isn't code, on the same record

Pricing, positioning, what to build next, and the days that end in a decision instead of a diff are all stuff just as important as code. That work gets the same treatment on its own stream with its own sign. Most build-in-public accounts show you the commits and quietly skip the thinking, which makes the work look more linear than it was.

You can do this. It is the same mechanism aimed at different work. Nothing about the machinery is code-specific; the coding stream just happened to be first, because a git workflow already had the moments to post at.

Every finished task carries what it cost

When a branch closes, its row publishes the measured cost of the session that did it: how many turns, how many tokens were written, and which model did the typing. Those receipts are what let /stats price the entire operation. We're proud to show what our own standing rules and tooling cost per turn before any real work starts.

The rule we hold ourselves to there is worth stating, because it is the one that makes the rest believable: a number goes up only if somebody watched a script print it. A figure that felt about right has gone out exactly once, and the correction is still on the record where it happened.

You can do this. An update body holds whatever your tooling can measure. If you can print it at the end of a job, you can post it beside the job.

Outages get written down while they hurt

There is a public incident task, written by us, while the site is still down. The uptime figure at the top of /stats is not a monitoring vendor's number — it is derived from that task, by pairing the update that opened each incident with the one that closed it. Which means the way to make our uptime look better is to break it less, and the way to make it look worse is to be honest, and there is no third option available to us.

You can do this. An incident log is just a task whose readers care about it more than usual. We model ourselves after companies we admire who make the record public before the outcome is known.

A dead session leaves a hole, and the hole is readable

Sessions die. Like most deaths, nothing announces it. What we get is a stream that opened something and went quiet, which is detectable, and the repair is a pair of backdated rows saying what happened and that they were written after the fact.

You can do this. Any update can carry the time it happened rather than the time it was posted. We treat backdating as something that documents itself rather than something to hide, which is why the reconstructions say so in their own text.

The machines are writers, not just readers

Most of the rows on our streams were posted by Claude, through a normal API key scoped to a single task. The public page labels them "via Claude skill," so you can always tell who typed what. That is not a special arrangement we gave ourselves — it is the documented write path, and the keys are mintable from any account.

You can do this. Every account gets 10 key-enabled tasks for free. Give it a spin and if it proves useful, then sign up to get more key enabled tasks. Tasks with updates only posted by humans are always free.

Proof rides along with the claim

When something gets verified on a real device, the screenshot goes on the update, not into a folder somewhere where you can't see them. (TBH, it does go into a folder too, but that's only cuz Tom wants them in a folder to easily catalog them.) It is a small thing that turns out to matter: the evidence and the claim travel together permanently, so a year from now the sentence and the picture that backs it are still one click apart.

You can do this. Attach images, video, audio or a PDF to any update. It is the same composer everybody has. There are some limits on the number of media and sizes allowed on free accounts. As of today, we still haven't hit the limits yet, so that should give you an idea of how generous it is.

What super power this dogfooding gives us

The results our product promises every user. The build log means a session that starts tomorrow can read what every other session did today without asking anybody the dreaded "What's the status?". The incident record means our uptime tracks to timestamped updates. The receipts mean a decision about our own process is a priced decision instead of a preference. And all of our decisions are public, which is the part that keeps it honest. If it was private, we might not keep records or we might forget to record the decisions. We removed that option from ourselves, so you know where things stand at all times.

The cost is real too. This only works because the work already had moments worth announcing, both good and bad. How do you think we got downtime? If you're going to trust us with your updates, then we owe you the insight into what's going on internally so you can plan accordingly.

The steps are back up here.