Service levels
What we aim for, how it is measured, and — at the bottom — which of these numbers have been proved by rehearsal and which are still objectives. That last section is unusual to publish. It is also the only part of a service level statement that tells you anything.
Availability
99.5% per calendar month, per instance. That allows about 3 hours 40 minutes of unavailability in a 30-day month. An instance is available when it answers a request to its own address.
Not counted against it:
- Announced maintenance, and the brief restart caused by a change you asked for — applying branding or a custom domain writes into your instance while it is stopped, and both say so before you confirm.
- Suspension for non-payment or for a breach of the acceptable use terms.
- Faults inside your own instance: a configuration you changed, a git hook you installed, a quota you filled.
- Failures of networks between you and us that we do not operate.
We do not offer automatic service credits. If we miss this badly enough to matter to you, email us and we will make it right — with a refund where that is the fair answer. A credit scheme that pays out 5% of one month is a ritual, not a remedy, and we would rather have the conversation.
Recovery objectives
| Objective | Target | What it means |
|---|---|---|
| Recovery point | 24 hours | Backups are nightly, so the most you can lose to a failure on our side is a day's work. You can also take a backup yourself at any moment. |
| Recovery time, one instance | 4 hours | From us noticing to your forge serving again. A self-serve restore of a 5 GB instance is aimed at 30 minutes and needs no ticket. |
| Recovery time, loss of a whole host | 24 hours | Rebuilding a replacement machine and restoring every instance onto it. |
Backups
Nightly, from a consistent snapshot, to two independent storage repositories with separate credentials, encrypted before they leave the host. Kept 7 daily and 4 weekly on Solo, 14 daily and 8 weekly on Team, and the most recent successful backup is never removed however old it is.
Restores are a feature you operate, not a ticket you raise. On a nightly schedule the platform also proves them, by restoring a backup into a scratch machine and booting it — described in section 6 of the data processing agreement, because it involves a copy of your data.
Maintenance and upgrades
Instances are kept on Forgejo's stable release line, which takes a major release each quarter, and the whole fleet runs one version. Upgrades are announced in advance by email, a backup is taken before an instance is upgraded, and we start with our own instance before yours.
Some changes need a restart of your instance — a Forgejo upgrade, branding, a custom domain. These are minutes, not hours, and the ones you trigger say so before you confirm.
Support
Email, at the address on the support page in the portal. We aim to reply within one business day, on a best-effort basis, and faster when something is down. There is no telephone number and no chat widget; the person who answers is the person who can fix it.
Security reports have their own faster path — see the security page.
What we have actually rehearsed
An objective is a promise about the future; a rehearsal is evidence. Here is the state of each, and this section changes as they are proved.
| Claim | Evidence |
|---|---|
| Signup, provisioning, push over SSH and HTTPS, backup, restore, delete | Proved once, end to end, on production hardware, by an automated run of the whole lifecycle. We require seven consecutive green days of it before taking a first paying customer, and the schedule that would produce them is not yet switched on. |
| Self-serve restore of one instance | Proved on production hardware, including that work written after the backup is correctly discarded. |
| Nightly backups to two repositories | Built and running. The platform's own drill is now built to read the second, off-site copy back in full one night in seven and boot a forge on it, so that both copies get proved rather than only the near one — but that has not yet run on production hardware, and neither has any restore from the off-site copy. Reading data back from the second copy has been proved against the storage provider directly, and not yet through a whole restore. See the row below. |
| Nightly restore drills — the platform proving its own backups | Not yet run on production hardware. The schedule and the drill are built and tested, and every green test of them so far has been against a stand-in rather than a real machine. Until that changes, our confidence that backups restore rests on the restores we have actually performed — the row above this one — and not on the drill. Described in section 6 of the data processing agreement, which says the same thing. |
| Recovery from loss of a whole host | Not yet rehearsed. The control-plane half of it will be rehearsed before we take a first paying customer; the part that rebuilds every instance onto a replacement machine is procedure without a rehearsal behind it. Restoring an instance's data out of the off-site copy — the copy that survives losing the machine and its provider together — is now something the platform can do rather than something it describes, but no such restore has yet been performed on production hardware, and making the replacement machine for it to land on is still done by hand. Treat the 24-hour objective as an objective. |
| Availability measured from outside our provider's network | Not yet. Monitoring today runs on the same host it watches, which cannot see an outage that takes the host with it. An independent probe and a public status history are required before launch; until they exist, the 99.5% above is a commitment we are not yet able to evidence to you. |
We would rather publish this table than a page of numbers with nothing behind them. If a row here matters to your decision, ask us about it — the answer will be as specific as the table.