> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.rebateright.com.au/reliability/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.rebateright.com.au/_mcp/server.

# Reliability

> **Note**
>
> These are real numbers, measured from live traffic. They are not promises: we do not offer a service level. Part of the path also runs on Services Australia's systems, which are not ours to control.

## Speed

Some requests we answer ourselves. The rest we check with Services Australia in real time.

**Requests we answer from our own data**MBS item lookups, benefit calculations, provider eligibility

**29*ms****Median*Half of these requests are faster **87*ms****95th percentile*19 in 20 are faster

**Requests that rely on Services Australia**Eligibility checks, patient verification, claiming

**364*ms****Median*Half of these requests are faster **863*ms****95th percentile*19 in 20 are faster

The difference between those two figures is the round trip to Services Australia. Both figures are measured server side, from your request reaching us to our response leaving us.

---

## Availability

**How often a request gets an answer.**

**Calls to Services Australia**Over the last 90 days

**99.98*%****Answered*

Of 264,835 calls over that period, 64 did not come back. That leg belongs to Services Australia, so it is the part of the path we depend on rather than run.

Our own figures are being gathered and will appear here.

---

## Where it runs

| Item           | Position                                                              |
| -------------- | --------------------------------------------------------------------- |
| Region         | Microsoft Azure, Australia East                                       |
| Data residency | Requests are processed in Australia                                   |
| Capacity       | Scales with demand. No fixed instance count                           |
| Releases       | Deployed automatically from source, with no scheduled downtime window |

[Security & Governance](/governance) covers data handling and the controls around it.

---

## Recovery time objective (RTO)

**How quickly the service comes back after an outage.**

Recovery is about the service, not your data. There is no database to replay and no backlog to clear, so what is left is one of four cases.

### If patient data is lost

**Nothing to restore**None is held, so none can be lost

**0***Recovery time*

There is nothing to bring back and nothing to wait for. Your account records come back with the service.

### If a restart is enough

**Capacity or configuration**The common case

**4.5*s****Median recovery time*

Most callers would not notice the interruption at all. A request that lands in the gap receives an error rather than being held in a queue, so you always know the outcome.

### If a new deployment is needed

**A problem in a recent release**Built from source and put live

**2.2*min****Median recovery time*

This is our build and deployment time: from starting a release, through building from source and deploying, to the service running the new version. There is no data to migrate and no state to rebuild. This is not a rehearsed recovery plan: it is the path every release already takes.

### If we have to find the cause first

We begin the moment we know, and we keep you informed until it is resolved. How long the search takes depends on what we find, so there is no number to publish here. Once we have the cause, the fix lands on one of the two clocks above.

---

## Recovery point objective (RPO)

**How much data you could lose.**

The measure is the gap between the last safe copy and the moment something goes wrong. Where nothing is retained, there is nothing to lose.

### Patient data

**Nothing is retained**Used while your request runs, then discarded

**0***Data at risk*

Patient names, Medicare card numbers, dates of birth and Individual Healthcare Identifiers exist only for as long as your request does. None of it is written to a database or a file, so there is no copy of it to fall behind or be lost.

### What we keep

We hold operational records: enough to authenticate your account, handle your billing and show your usage reports. Your API key is held only as a one-way hash, never in a readable form.

Losing those records would not put patient data at risk, because none of it is there to lose. [Security & Governance](/governance) sets out what we hold and how it is protected.

> How fast RebateRight answers, where it runs, how it recovers, and how much of your data is ever at risk