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. Compare it with a check 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 when one reports an incident on its own status page, and again when it reports it resolved; for a service with no status feed we can read, when our checks of it fail from two or more distant regions, and again when they pass, and each alert says which of the two it is.
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 check results and a probe event log going back to when coverage started for that service. Individual closed probe events also get their own permanent record page, indexed forever, so a specific event 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, a record to attach to a support ticket or a credit claim; the vendor decides what counts, and it is 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.