Home/Developers/Status
You will not find an uptime percentage or a past incident record here — because there is no production environment yet. The product is in Phase 0: every component is in development. This page will be fed by live health data the day we go to production.
Source of status: hand-updated phase information · not live measurement
Components
The states below describe the local development environment. "Development" means the component has code but promises nothing to anyone in production.
The colours in this table: an orange dot means development, a grey dot means not started. A green dot in this table will be used only for a component running healthily in production — today none of them is in that state. A green dot on the other pages of this site means "written within Phase 0 and running in local development", not production health.
Once we are in production this list will be fed by health probes rather than by hand: each component's response time measured from outside, its error rate and the time of the last check. An uptime percentage will be published only after we start measuring, and with the measurement window written next to it — we will not publish a number calculated backwards.
Because there is no system carrying customer traffic yet; a system that does not exist cannot have an outage. When the first real outage happens it will be published here with its date, its duration, the component affected and its root cause — the accurate record, not the flattering one.
Incident reporting
Let the policy be written now, so nothing is up for debate on the day of the first incident. The flow below takes effect when we go to production.
If a component fails its health check, the status here changes first, then a warning banner appears in the console. Affected users also get an email. We announce the incident even when we do not know the cause; "we are investigating" is a notification too.
While the outage lasts, if your pod is failing its health check those seconds are not billed in the first place — you do not have to file anything, the metering engine writes those seconds to a separate counter. This is what "you don't pay for seconds that don't work" means on the day of an outage.
After the incident is closed, a closing note lands here: what happened, how long it lasted, who was affected, what changed to stop it happening again. A text that fixes the system, not one that looks for someone to blame.
SLA
In a marketplace the supply comes from the community and from providers; making the same promise for every machine would not be honest. That is why the SLA arrives together with a tier.
No SLA, but a guarantee: you don't pay for seconds that don't work. If a node fails its health check, billing stops; moving the job to another host is the intended behaviour and will be wired with Temporal at the end of Phase 0.
Audited data centres and contracted hosts. Uptime commitments, response times and compensation rules are given at this tier — this is the product enterprise sales sells. It does not exist yet; the contract text has not been written.
With the first beta the channel and the target response time will be written here. We are not making that promise today, because we have no on-call team to keep it.
If you ever see an uptime percentage, the measurement window and the source will be written next to it. We do not publish percentages without a source.
Planned maintenance
The planned maintenance policy — it takes effect when we go to production:
This policy is a description of how we work, not a contract text. The binding texts are collected under Terms of Use.
Follow
The changelog tells you what shipped, the security page tells you how it is protected. The promise stays the same: you don't pay for seconds that don't work, a hard budget cap, per-second billing.