Status
Is it working?
Current state of every service, the uptime we have observed over the last 90 days, and an honest write-up of everything that has broken recently.
API
The service the product and every agent run talks to.
Web application
The board, plans, reports and everything you click.
Agent run scheduler
Dispatches tasks to specialists and holds work that is waiting on a dependency or a gate.
Deployment pipeline
Merges approved branches, runs your deploy command, your health check and, when needed, your rollback command.
Investigations
Opens on a failed run, reads logs and diagnostics at read-only access, and writes up what it found.
Git integrations
Cloning, branching, worktree creation and pushing against your connected repositories.
Notifications
In-product alerts: a plan awaiting approval, a gate opened, a health check failed. Slack delivery is roadmap, not shipped.
Bars cover the last 90 days, one bar per period, newest on the right. These are observed figures describing what happened. They are not a service level agreement, they carry no remedies, and we do not offer one — see the roadmap for where a contractual SLA sits.
Recent incidents
What broke, and what we changed
Every incident gets a write-up in the same shape: what happened, who it affected, and what is different now. We name systems and decisions. We do not name the person who pressed the button, because that has never once made a system safer.
What happened
A migration on the run scheduler's queue table took a lock we had assumed was cheap. New tasks were accepted and stored but never dispatched for 93 minutes.
Impact
Around a third of projects saw tasks sit in a waiting state. No work was lost, no branch was left half-merged, and no deployment ran against a stale plan. Runs already in flight finished normally.
What changed
Migrations that touch the queue now run behind a lock timeout and abort rather than wait. We added an alert on dispatch age rather than only on queue depth, which is the signal that would have caught this in three minutes instead of forty.
What happened
A change to our SSH connection pooling shortened the window a health check had to respond in. Slow but healthy checks were recorded as failures.
Impact
Eleven deployment runs rolled back automatically despite the deploy itself having succeeded. Rollback worked exactly as designed, so no customer was left on a broken commit — but four teams were woken up for nothing, which we count as an outage.
What changed
Health check timeouts are now set per deployment target rather than globally, and a timeout is reported as a distinct outcome from a failure, so you can see which one you had. We also wrote to every affected team the same morning rather than waiting for the write-up.
What happened
An upstream git host was rate-limiting us harder than its published limits suggested. Our retry logic backed off politely, then queued, then fell behind.
Impact
Clone and push operations were slow for two and a half hours for projects on that host. Some tasks took several minutes to acquire a worktree. Nothing failed permanently and no repository was left in a bad state.
What changed
We now spread git operations across more connections per host and surface the wait in the run stream, so you can see the reason rather than watching a task appear stuck. The native GitHub and GitLab app on the roadmap removes most of this class of problem.
Definitions
What each status level means
So that "degraded" means the same thing on this page every time.
Operational
Degraded
Partial outage
Major outage
Maintenance
How this page is made
Two things you should know before trusting it
Seeing something we are not?
Tell us what you are seeing and roughly when it started. Include a run or deployment reference if you have one. A person reads it.
Incidents written up within two working days · No blame, named systems