Service Level Agreement

Last updated: 16 August 2026

This page explains how available we aim to keep Niro, how we measure it, and what does not count.

It forms part of our Terms of Service.

Our commitment

We aim to keep Niro available 99.9% of the time, measured each calendar month.

To put that in real terms, 99.9% allows about 43 minutes of downtime in a 30 day month.

What "available" means

Niro is available when our service answers a valid request normally.

We measure two things:

What we measure Address
The orchestrator, which handles projects, repositories and code analysis aiorchestrator.niroai.dev
The assistant, which handles chat, questions and the MCP server aiassistant.niroai.dev

Both must be answering for the service to count as available.

How we measure it

An independent monitoring company checks both addresses from several locations around the world, every minute. We do not mark ourselves.

To work out the monthly figure:

Take the total minutes in the month. Take away the down minutes. Divide by the total minutes.

For example, in a 30 day month there are 43,200 minutes. If 20 of them were down, that is 99.95%.

What does not count as downtime

This is the part worth reading carefully, because every SLA has exclusions and it is fairer to be plain about ours.

Planned maintenance. We will tell you at least 48 hours beforehand. We keep it under 4 hours a month, and we do it outside UK business hours whenever we can.

Emergency security fixes. If we have to patch something urgently to keep you safe, we will do it and tell you as soon as we can.

Problems at your end. For example your own network, your firewall, or a repository you have disconnected.

Outages at companies we depend on. For example your git provider, or an AI supplier. We list who we depend on on our Sub-processors page.

Events outside anyone's control. Major internet failures, and similar.

Features marked beta or preview. These are still being built, and we say so when you use them.

Suspension for non-payment or for breaking the Terms.

The quality of an answer. This one is worth its own section, below.

Available is not the same as useful

This is the part people most often misunderstand, so here it is in full.

If Niro answers you, Niro is up. Downtime means we did not answer at all.

That includes the times when the honest answer is "I do not have enough information about this". Niro is designed to say so rather than to guess. If our MCP server tells your coding agent to use its own tools instead, because the index does not cover what you asked, that is Niro working correctly. It is not an outage. Guessing would be the failure.

None of these count as downtime:

What does count as downtime: we return an error, or we do not respond at all.

Speed is not availability either

This SLA covers whether you can reach Niro. It does not cover how long an analysis job takes to finish.

Indexing a large repository takes longer than indexing a small one. That is normal, and it is not downtime.

Deployments

We release updates using a method called blue/green. In plain terms, we start the new version alongside the old one, check the new version is healthy, then move traffic across and retire the old one.

You should not see anything. Releases are not planned maintenance and they are not excluded from our uptime figure. If a release causes an outage, it counts against us. That is deliberate, because it keeps us honest about how we ship.

Asking for the numbers

Email ask@niro.ai and we will send you the uptime figures for any month.

Changes to this page

If we change this SLA in a way that reduces what we promise, we will give you 30 days' notice first.

Contact

Support: ask@niro.ai Security: privacy@niro.ai