Vendor SLA Monitoring and Vendor SLA Tracking for Third Party APIs and Services

You monitor a vendor's SLA by measuring the covered service yourself, from outside the vendor's network, at an interval short enough to settle the target in the contract, and keeping the results for longer than the claim window. Status pages and vendor dashboards are useful context, but they are the vendor's own account of events and are written after the fact.

In practice that means three choices. First, the endpoint: it has to be the service the SLA covers, not the vendor's marketing site. A payment provider's homepage can be up while its charge API is failing. Second, the interval: at 5 minute checks an outage of 30 seconds and an outage of 9 minutes can look identical, so for 99.9 and 99.95 percent commitments you want 60 second checks. Third, retention: if your contract lets you claim within the quarter, a tool that keeps 30 days of history cannot support the claim. Professional keeps 90 days and Enterprise keeps everything.

The same record helps beyond credits. At renewal, a year of dated incidents is a far stronger argument for a discount or an exit than a general feeling that the service has been flaky.

The budget is smaller than most people expect. These figures are plain arithmetic for a 30 day month, which is how most uptime clauses are measured.

A single 45 minute incident breaks a 99.9 percent month. Two 15 minute incidents break 99.95. At 99.99 percent the whole budget is shorter than one 5 minute check interval, which is why Starter's 5 minute checks are fine for spotting outages but not for settling an argument at that level. For SLA evidence, use Professional or Enterprise. If you also publish an SLA to your own customers, the uptime report page shows how the same report reads from the other side of the table.

You prove an SLA breach by sending the vendor a written credit request that names the clause, states the measured availability for the period, and attaches the dated outage records behind that figure. Most providers do not pay credits automatically, and many set a deadline for claims, so read the contract for both before the month you need it.

A claim that gets paid usually has four parts. The period and the target from the contract, such as October and 99.9 percent. The measured result, for example 99.82 percent, which is about 78 minutes down. The incident list: each outage with its start, end and duration, which is exactly what the incident log and the CSV export contain. And your own support tickets for the same times, if you opened any, which is easier when the phone rang during the outage rather than the next morning.

Expect the vendor to apply its own definitions. Many contracts exclude scheduled maintenance, count only outages longer than a few minutes, or measure from their own probes. Your record will not override the contract, but it changes the conversation from "we saw nothing on our side" to a list of times they have to explain. If they claim an outage was planned maintenance, you can check it against the notice they sent.

Anything you pay for that sits on your revenue path and comes with an availability promise. The usual list for a US business looks like this.

• Payment and checkout providers. A gateway or processor outage stops sales outright, and the API health endpoint is easy to check.
• Hosting, CDN and managed platforms. Monitor your own site through them; if your origin is healthy and the site is down, the record points at the provider.
• SaaS your team or customers log into. Help desk, scheduling, practice management, the CRM the sales team lives in. A login page that returns 5xx is a breach worth logging.
• Data and API suppliers. Shipping rates, address verification, market data, identity checks. If your app calls it, its downtime is your downtime.
• ISPs and connectivity. Monitor a public endpoint you host behind the line; a pattern of outages that only that site shows is the basis for a conversation with the carrier.

The SaaS uptime monitoring page covers the other half of this, watching your own product against the SLA you sell.

It is worth knowing the limits before you build a claim process around any tool, including this one. Checks come from our monitoring network rather than from a set of cities you choose, so the record cannot show that a vendor was down only in one region. Each check is an HTTP request with a status code test. It does not log in, click through a checkout or confirm the content of the page. There is no setting to exclude the vendor's announced maintenance window from the percentage, so you subtract those minutes yourself using the incident log.

Reports are opened in the panel and saved or printed when you need them; they are not emailed to a list on a schedule. Each report covers one endpoint. And our measurement is evidence, not the contract's definition of downtime. If the SLA says availability is measured by the vendor's own probes, your log is what you use to challenge their figure, not a replacement for it.

If you need multi-region proof or scripted transaction checks against a vendor, a synthetic monitoring product built for that is the better buy. Our comparison of uptime monitoring tools for SLA reports and downtime evidence names the ones that do it and what they cost.