Reliability
We cannot be better than the cloud under us.
A prty cluster is made of the cloud’s virtual machines, disks and DNS. Whatever availability those services commit to is a ceiling on ours. This page shows the ceilings, what we engineer for below them, and what we have measured.
Our SLA today: none. We do not offer service credits yet. The numbers in “What we engineer for” are objectives (SLOs): targets we design and test against, not promises. We will publish an SLA when we have enough operating history to stand behind one. If you need one first, talk to us.
1. What the clouds commit to
These are the providers’ own published commitments for the pieces a prty cluster is built from. Each cloud offers different things, with different definitions of “unavailable”, so the numbers are not interchangeable. Read the scope column.
AWS (where prty runs today)
| Service | Commitment | What it covers | SLA text last updated |
|---|---|---|---|
| Amazon EC2 | 99.99% | Region-level: unavailable only when all your running instances in two or more AZs of a region concurrently have no external connectivity.99.5% for a single instance. | May 25, 2022 |
| Amazon EBS | 99.99% | Region-level, for all running volumes deployed across two or more AZs.99.9% for each individual volume. | May 31, 2022 |
| Amazon Route 53 | 100% | Authoritative DNS of a hosted zone: credits start below 100%. The SLA text does not say whether private hosted zones are covered. | April 16, 2025 |
| Amazon RDS (managed PostgreSQL, for comparison) | 99.95% | Multi-AZ DB instances and Multi-AZ DB clusters.99.5% for a single-instance (not Multi-AZ) database. | January 22, 2024 |
Google Cloud (not supported by prty; shown for comparison)
| Service | Commitment | What it covers | SLA text last updated |
|---|---|---|---|
| Compute Engine | 99.99% | Instances in multiple zones of a region, Premium network tier (99.9% on the Standard tier).99.9% for a single instance (99.95% for memory-optimized machines). | October 14, 2026 |
| Cloud DNS | 100% | Serving DNS queries from at least one of Google's managed authoritative name servers. | January 9, 2020 |
| Cloud SQL for PostgreSQL (managed, for comparison) | 99.95% | Enterprise edition with high availability.99.99% for Enterprise Plus with high availability. Single-zone instances are not covered. | October 3, 2025 |
Read on 2026-10-17. The commitment is the percentage the provider tries to meet in a month; the remedy for missing it is a service credit on the bill, not compensation for your outage. Cloud SLAs are conditional (for example, AWS’s EC2 region-level commitment concerns all your instances in two zones being unreachable together, which is a much rarer event than a single machine failing).
Three things to notice
- The strongest compute and disk commitments on both clouds are 99.99%, and only for deployments spread across zones. That is about 4.4 min a month. It is the ceiling for anything built on them, prty included.
- A single instance or a single disk is committed at 99.5% to 99.9%: between 44 minutes and 3.6 hours a month. This is why a database is never one machine here.
- The managed PostgreSQL services commit to 99.95% (RDS Multi-AZ, Cloud SQL Enterprise HA). Google’s top edition commits to 99.99%. We say our own objective plainly below, and it is lower than that.
2. From those numbers to a cluster
A client reaches the primary through a DNS name, a virtual machine and its disk. Those are in series: if any is down, the client is. Three members in three zones put the machines and disks in parallel, and the cluster is up while any two of the three are. A simple model of that, using only the weakest numbers the providers commit to:
- One member is its VM at 99.5% and its disk at 99.9%, so a member is up 99.401% of the time.
- The cluster is up when at least two of its three members are. If members fail independently, that is 99.989%, about 4.7 min a month.
- That is already close to the 99.99% ceiling, and it is before the pause for each failover.
This is a model, not a measurement. It assumes independent failures, which zones are built to provide but a regional event can break, and it leaves out everything that is ours: failover time, software bugs, operator mistakes. It shows that three members in three zones are enough to reach the clouds’ ceiling on paper, and that the ceiling, not our design, is what limits the promise.
3. What we engineer for (SLOs)
Objectives for a three-member cluster in three zones on AWS. They are targets and not an SLA; the right column says what we have actually seen.
| Objective | Target | What we have seen |
|---|---|---|
| Availability for writes, per month | 99.9% | Up to 43.8 min a month of unavailability. Below the 99.95% of RDS Multi-AZ, deliberately: we will not claim a number we have not operated at. Ceiling: 99.99%. |
| Automatic failover: primary lost, writes accepted again | ≤ 60 s | 29.5 s and 30.1 s on AWS (the writer’s longest gap). The design is 25–35 s: 20 s that the old primary needs to be sure it has stopped, plus promotion. |
| Acknowledged commits lost in an automatic failover | 0 | None in the AWS chaos suite or the soak. Exception, stated in advance: a cluster that has been running degraded (its replica gone, writes continuing without it) does not fail over by itself, because that could lose data. A person decides, and the loss is measured first. |
| Planned switchover (maintenance) | seconds | No acknowledged write lost. Clients using the cluster’s DNS name saw a pause of up to 10 s on AWS, most of it DNS propagation; clients that list all members in their connection string reconnect faster. |
| Reachability | private only | No public addresses on databases, enforced by the network layout. |
Where the targets stop
Two members lost at once is an outage. A three-member cluster needs two to elect a primary and to commit. In one of our soak runs, AWS stopped a test spot instance while another member was already down, and writes stopped for 21 minutes until a machine came back. That happened on interruptible instances we use only for testing, never for customers’ databases, but the arithmetic is the same on any instance: two of three gone means no majority, and no clever software changes it. We track making this case rarer and shorter as an open issue.
What this does not protect against: an outage of a whole region, a provider’s control plane being down (we cannot replace machines then), a customer’s own bad queries or schema changes, and data corruption caused by PostgreSQL itself or by the application. Backups and point-in-time recovery, the defence for several of these, are not built yet (roadmap).
4. Other clouds
Google Cloud’s numbers are the same shape as AWS’s: 99.99% across zones, 99.9% for one instance, and a managed PostgreSQL at 99.95% (99.99% in the higher edition). Each cloud offers different building blocks, so the ceiling is recomputed per cloud from its own table above, not copied. We would do that again before running anywhere new. We run on AWS only.