1. Know what the percentage actually promises
An SLA target like 99.9% is a ceiling on downtime over a stated period, usually a month or a year, computed after the fact, not a live status. It says nothing about how the failure was distributed: a vendor can burn an entire month's allowance in one bad afternoon or spread it across a dozen five-minute blips and land on the exact same percentage.
2. Use the calculator instead of doing the math by hand
realuptime.io/tools/sla-calculator is a free, no-signup tool: type any target percentage and it shows the exact downtime allowed per day, week, month, and year. The common targets people search for by name, two nines through five nines, each also get their own dedicated page under /tools/sla-calculator/<target> with the full breakdown already computed, so there's rarely a reason to re-derive the arithmetic yourself.
3. A vendor's stated SLA is a claim, not a measurement
The percentage in a contract or on a status page is whatever the vendor's own systems and staff decided to publish. Nothing forces it to reflect what an independent observer outside their infrastructure actually saw, and a status page maintained by the team busiest during an incident has every incentive to under-report rather than over-report.
4. Verify it with a probe reading of your own
realuptime.io/kb/monitor-a-vendor-api-your-business-depends-on covers vendor watch: adding a vendor like Stripe, GitHub, or AWS to your own account puts RealUptime's own probe reading for that vendor on your dashboard, shown separately from the vendor's own status-page claim, never merged into one number. Alerts fire only on a probe-confirmed measured event, so what you see is what was actually checked, not what was said.
5. Check the historical record before you sign, not just the live status
Every tracked service in the outage catalog has a permanent history page at realuptime.io/outages/<service>/history, with region-by-region availability and a probe-detected incident log going back to when coverage started for that service. Individual closed incidents also get their own permanent record page, indexed forever, so a specific outage a vendor's sales deck glosses over stays citable with its own stable URL rather than aging out of view once it drops off a live dashboard.
6. Generate evidence if the vendor misses its own number
Each watched vendor's dashboard tile links to a Generate SLA evidence report action, the same probe-measured evidence report available from that vendor's own public outage page. It's built from the same measurements as the history page, useful evidence for a support ticket or a credit claim against the vendor's own contract, not a number RealUptime asserts on its behalf.
Go deeper
The full reference lives in the docs: Monitor documentation. Error codes named above are each explained in the error-code reference.