Service level agreement

A statement of how Rotaaa is operated and what you can expect when something goes wrong. It is part of the terms of use. Where this document and any page on this site disagree about availability, support or incidents, this document governs; on every other subject the terms govern, and clause 18 of the terms states the same rule from its side.

Rotaaa costs nothing, so there is no payment to refund and no credit to issue. What this document offers instead is a measurable commitment and a plain account of how the service is run.

The Rotaaa application at rotaaa.app, the database behind it, and the public site. Every customer is on the same service: there is no tier that buys a stronger commitment than the one written here.

Not covered: your own internet connection, your devices, and the two providers Rotaaa depends on — Clerk for sign-in and Resend for invitation emails. Each of those runs to its own terms and its own status page, and an outage at either is visible here as sign-in failing or invitations not arriving.

Rotaaa commits to 80% availability in each calendar month.

Availability is measured from recorded health checks. Each time the service is checked — the check confirms that the application answered and reached its database — the result is recorded with the time it was taken. A month’s availability is the share of that month’s checks that succeeded, and the running figure is published per component on the status page, which shows what was measured rather than what was promised.

The limit of that record. A second check runs outside the application, once a minute, and writes down an outage the application is too broken to report itself. It runs on the same machine, so a total hardware failure records nothing at all — only a probe somewhere else would close that, and until there is one the figure can understate a long outage. An outage is reported in the incident record on the status page whether or not it marked the figure, and it is the incident record that a month is judged against.

What counts as downtime. Any period in which the application does not answer, or answers but cannot reach its database, so that the product cannot be used.

What does not count. Maintenance announced on the status page in advance; faults in your own network, devices or browser; and outages at the providers named in clause 2 — Clerk for sign-in, Resend for invitation emails — which are outside our control and are reported rather than absorbed.

If the target is missed. Rotaaa is free, so there is no fee to credit and this agreement invents no credit scheme for a product nobody pays for. The remedy is disclosure: a month that falls below 80% is stated as such on the status page, with an incident report explaining what happened, what was affected and what has been changed to prevent a repeat. That report is published whether or not anybody asks for it.

By us, or by you telling us. The service records its own health as it goes, so an outage leaves a trace in the record — but nothing wakes anybody up. There is no paging system and no on-call rota: out of hours, the trace sits in the record until somebody looks at it.

This is the reason reporting a problem matters more here than it does with a larger provider: a message about something broken at two in the morning is likely to be the first anybody knows of it. Report it at [email protected] from any address, or from the support screen inside the product if you are an owner or an administrator — the contact page sets out both routes.

Every deployment follows the same scripted sequence, and it is built to fail safely rather than quickly:

• the test suite runs first, on a machine that cannot affect the live service — a failing test stops the deployment there;
• the new version is built on the server before the running one is restarted, so a build that fails never reaches anybody;
• database migrations run ahead of that build, and a failed migration stops the deployment with the previous version still serving;
• the previous build is kept, and the site is checked afterwards for a real render rather than a bare status code;
• if that check fails, the previous build is restored and restarted automatically.

Rotaaa changes often, and individual changes are not announced. A change that would alter or remove data you have entered is announced in advance, on the status page, before it happens.

Support runs through [email protected], which anybody can write to, and through the support screen inside the product, which is open to owners and administrators; the contact page sets out both. We aim to read and answer messages seven days a week, and often reply within the hour. That is an aim; the targets below are the commitment, and where the two differ these are what we are held to.

Working days are Monday to Friday, excluding England and Wales bank holidays. A message that arrives outside a working day starts its clock at the beginning of the next one; that start rule takes effect on 19 October 2026, for the reason given at the top of this page. These are targets for a first substantive reply, not for a resolution, and not a guarantee:

• Service down, or data at risk — worked on as soon as it is seen, with a reply the same working day.
• Something is broken but there is a way round it — a reply within two working days.
• Questions, requests and suggestions — a reply within five working days.
• Data protection requests — an answer within one month, extendable for a genuinely complex request as the privacy policy sets out.

Common questions are answered on the support page, which is quicker than any of us.

The status page is where an incident is posted and updated, and where it stays afterwards as a record. An incident that affected data — not merely availability — is also written up there, plainly, rather than summarised as “a brief degradation of service”.

The timings, so that “posted and updated” means something. Every one of these is measured from the moment the outage is NOTICED, not from the moment it began. Clause 4 says plainly that nothing pages anybody, so a commitment measured from the start of a fault would be a commitment to something nobody is awake for.

• An incident is opened for anything that stopped the product being usable for more than 15 minutes, for any interruption at all that affected data, and for any planned work that required downtime. Shorter blips are not written up: a record of every thirty-second wobble is a record nobody reads, which is the same failure as a page that is always green reached from the other direction.
• The first post goes up within 2 hours of it being noticed, even when the cause is not yet known — “something is wrong and it is being looked at” is the post, and waiting for a diagnosis is how a status page ends up silent through the outage it exists for.
• While it is open, an update at least every 4 hours during the working day, and one at the start of the next working day if it runs overnight. An update saying nothing has changed is still an update.
• A closing post when it is resolved, saying what it was.
• A written-up report within 5 working days of resolution, for any incident that affected data and for any month that falls below the target in clause 3: what happened, what was affected, and what has changed so it does not happen again. Published whether or not anybody asks.

An incident record is never edited or deleted once posted. An update is something that was said at a time, and a history that can be rewritten is not a record. Where an earlier post turns out to be wrong, the correction is a new update that says so.

Planned maintenance that requires downtime is announced on the status page beforehand wherever the work allows it, and is scheduled outside typical shift-planning hours where there is a choice.

Your data lives in a PostgreSQL database that we operate ourselves rather than a managed service somebody else runs. No restore has been rehearsed as part of Rotaaa, so this document does not promise a recovery point or a recovery time, and will not until one has been tested end to end.

That is a reason to keep your own copy of anything you could not reconstruct. You can take one whenever you like: the organisation settings screen has a Download a copy control that produces the whole account — people, rotas, leave, allowances and timesheet entries — as a single file, and locations, departments, job roles, the people list, timesheets, the leave register and both reports each export to a spreadsheet from their own screens. If you cannot reach those controls, ask us and we will provide a copy.

If a personal data breach affected data your business holds in Rotaaa, we will tell you without undue delay, and in any event within 24 hours of becoming aware of it, with enough detail to meet your own obligations as the controller — what happened, which data and whose, when, and what has been done about it. Where we do not yet know something, we will say so and follow it up rather than wait.

Becoming aware means the point at which we identify the breach or somebody reports it to us, which is how clause 7 measures its timings and for the same reason: clause 4 states that nothing pages anybody out of hours. The 24 hours runs from that point, not from the moment the breach began.

You will not be told that “an issue was identified and resolved”. Reporting to the Information Commissioner’s Office, and to the people affected where that is required, is yours to do for your staff’s data and ours for the sign-in accounts we control; we will help you with yours. Clause 12 of the terms is where this commitment binds us contractually.

Rotaaa is free. There is no fee to credit and no refund to make, so this agreement offers no financial remedy, and the terms set out how liability is limited and what that limit is. Your remedy for a service that is not good enough is to stop using it and to take your data with you, which will be helped rather than hindered — clause 8 says how, and it takes one click.

This agreement is revised as the way Rotaaa is operated changes — and the intended direction of every revision is a stronger commitment, not a weaker one: monitoring that reaches somebody, a probe that does not share a machine with the thing it watches, a rehearsed restore. Each revision carries a version number, an effective date and a summary of what moved, at the top of this page.

A revision that weakens anything committed here takes effect no sooner than thirty days after it is published, which is the same notice the terms give for a change that reduces your rights. A correction that runs in your favour takes effect when it is published, because there is nothing to give notice of.