Reliability | RebateRight

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.

Requests we answer from our own dataMBS item lookups, benefit calculations, provider eligibility

29msMedianHalf of these requests are faster

87ms95th percentileNineteen in twenty are faster

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

364msMedianHalf of these requests are faster

863ms95th percentileNineteen 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.

Calls to Services AustraliaOver the last 90 days

99.99%Answered

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 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

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 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

Capacity or configurationThe common case

4.5sMedian recovery time

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

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, 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

Nothing is retainedUsed while your request runs, then discarded

0Data at risk

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