Reliability | RebateRight

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 dataMBS item lookups, benefit calculations, provider eligibility

29msMedianHalf of these requests are faster

87ms95th percentile19 in 20 are faster

Requests that rely on Services AustraliaEligibility checks, patient verification, claiming

364msMedianHalf of these requests are faster

863ms95th percentile19 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 AustraliaOver 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 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 restoreNone is held, so none can be lost

0Recovery 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 configurationThe common case

4.5sMedian 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 releaseBuilt from source and put live

4.7minMedian recovery time

Measured from starting the release to the service running it. 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 retainedUsed while your request runs, then discarded

0Data 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 sets out what we hold and how it is protected.