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

# Reliability

These are real numbers measured from live traffic, not estimates. We stop short of promising them, because part of the journey runs on Services Australia's systems. What we do promise is to keep improving the reliability and speed of RebateRight.

## Speed

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

<strong>
  Requests we answer from our own data
</strong>

MBS item lookups, benefit calculations, provider eligibility

<b>
  29

  <i>ms</i>
</b>

<em>
  Median
</em>

Half of these requests are faster

<b>
  87

  <i>ms</i>
</b>

<em>
  95th percentile
</em>

Nineteen in twenty are faster

<strong>
  Requests that rely on Services Australia
</strong>

Eligibility checks, patient verification, claiming

<b>
  364

  <i>ms</i>
</b>

<em>
  Median
</em>

Half of these requests are faster

<b>
  863

  <i>ms</i>
</b>

<em>
  95th percentile
</em>

Nineteen in twenty are faster

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

---

## Availability

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

<strong>
  Calls to Services Australia
</strong>

Over the last 90 days

<b>
  99.99

  <i>%</i>
</b>

<em>
  Answered
</em>

About one call in ten thousand did not come back. That leg belongs to Services Australia, so it is the part of the path we depend on rather than run.

We are gathering our own figures now and will publish them 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 first, so what is left is one of four cases.

### If patient data is lost

<strong>
  Nothing to restore
</strong>

None is held, so none can be lost

<b>
  0
</b>

<em>
  Recovery time
</em>

There is nothing to bring back and nothing to wait for. Your account records do need restoring, and they come back with the service. If they could not, you can generate a new API key yourself straight away.

### If a restart is enough

<strong>
  Capacity or configuration
</strong>

The common case

<b>
  4.5

  <i>s</i>
</b>

<em>
  Median recovery time
</em>

Often the interruption is one no caller would notice. A request that lands in the gap gets an error rather than being held in a queue, so you always know where you stand.

### If a new deployment is needed

<strong>
  A problem in a recent release
</strong>

Built from source and put live

<b>
  4.7

  <i>min</i>
</b>

<em>
  Median recovery time
</em>

Measured from starting the release to the service running it. There is no data to migrate and no state to rebuild, so 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, we keep you informed throughout, and we do not stop until you are working again. How long the search takes depends on what we find, so there is no honest number to put 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

<strong>
  Nothing is retained
</strong>

Used while your request runs, then discarded

<b>
  0
</b>

<em>
  Data at risk
</em>

Patient names, Medicare card numbers, dates of birth and Individual Healthcare Identifiers live 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, bill you accurately, and show you 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.