Service status and incidents

Hosted-service availability and incident history belong on an independently hosted status page, reached from the TOVIO sites. Independently hosted is the load-bearing word: a status page that shares a failure domain with the thing it reports on goes down exactly when you need it. The marketing site only links to it and never synthesises service health or uptime of its own.

What it covers

Hosted services only, reported as separate public components so one incident does not imply another:

• Website

• Documentation

• Authenticated app

• Forge API

• Billing — kept independent of the API component, so a payment-provider or metering incident does not read as repository data being unavailable.

What it does not cover

TOVIO running on your own machine, or a Forge you run yourself. Those depend on nothing of ours.

This is worth emphasising, because it inverts the usual expectation: local work does not depend on any TOVIO service. Committing, branching, resolving conflicts, reading history, and decrypting content you hold keys for all work with no network at all. A hosted incident does not stop you working — it affects syncing with the hosted service.

During an incident

The status page carries what is affected and moves through explicit states — investigating, identified, monitoring, resolved — recording the affected components, the event times, the impact, and the mitigation. Subscriber notification and scheduled-maintenance windows are part of the page rather than a separate announcement channel.

Only customer-impacting state is published. Internal diagnostics, tenant identifiers, request bodies, secrets, provider responses, and any protected-content context stay in the private incident record — a status page is a public surface, and treating it as one is a permission decision as much as a communications one.

Please do not open a board post about an ongoing incident. It splits the conversation, and the status page is faster.

After one

Every incident record names its follow-up owner alongside the impact and the mitigation, so a resolved incident has someone attached to it rather than closing into nothing. What is published afterwards, and in how much detail, is decided per incident — treat a public write-up as something to ask for rather than something promised in advance. The one written commitment to a public technical post-mortem is in the security policy, and it covers critical vulnerabilities rather than availability incidents.

The public history begins when independent monitoring is activated; uptime and incident history are never backfilled or seeded with invented figures, so a short history means a short history rather than a good record.

Security incidents

Handled through the coordinated-disclosure process rather than the status page. To report something, use security@tovio.dev — never a public board. Note that until a PGP key or private vulnerability reporting is published, those reports travel over ordinary email, so keep proof-of-concept material minimal.

On availability commitments

Do not read a status page as a service-level agreement. Public availability commitments become effective only after the monitoring evidence and the launch gates behind them are complete; until then there is no uptime figure to hold anyone to.