# SLA and Uptime Commitment Change Monitoring for Vendor Contracts Source: PageCrawl.io Blog URL: https://pagecrawl.io/blog/sla-uptime-commitment-change-monitoring Published: 22 September, 2026 --- The postmortem was nearly finished when the platform lead pulled up the vendor's SLA page to work out what the outage was worth in credits. Four hours of degraded queue processing, a customer-facing incident, an apology email already sent. He had the number in his head from the procurement review: 99.95%, with a 25% credit below that. The page said 99.9%, and the credit table now started at 10%. The version note at the bottom carried a date from two quarters earlier. Nobody had done anything wrong. The vendor had published a new SLA at a URL that had not changed, and the old terms stayed in force only for customers who had negotiated an effective date into their master agreement. His company had not, and the renewal had auto-executed against whatever was on the page. The credit claim was worth roughly a third of what he had budgeted, and the reliability assumption baked into his architecture, the one that justified running a single region, had been downgraded while he was not looking. SLA pages are the strangest document in a vendor relationship. They read like contracts, they are referenced by contracts, and yet most are ordinary web pages the vendor can edit at will. Uptime targets get restated. Credit tiers get restructured. Exclusion clauses gain a line about "planned maintenance" or "third-party network conditions." Maintenance windows widen. None of it arrives in your inbox, because there is no obligation to send it and no product manager whose job it is to announce a worse guarantee. This guide covers what actually changes on SLA pages, which vendor pages deserve a monitor, how to set up tracking that alerts on substantive edits instead of every timestamp tick, and what to do with the alert once it lands. ### Why do vendor SLA pages change without anyone telling you? Because most SLAs are published as living web pages rather than executed documents, and the contract incorporates them by reference to a URL. The vendor updates the page, the reference still resolves, and the notification obligation, where one exists at all, is often satisfied by the act of publishing. Look at how the major providers structure this. Google publishes a directory of per-product agreements at [Google Cloud Platform Service Level Agreements](https://cloud.google.com/terms/sla), each with its own page and revision history. Amazon maintains separate documents per service family, including the [Amazon Compute Service Level Agreement](https://aws.amazon.com/compute/sla/), which sets a region-level Monthly Uptime Percentage commitment and a tiered credit schedule paying out progressively more as availability falls further below target. Microsoft consolidates its commitments into the [Service Level Agreements for Microsoft Online Services](https://www.microsoft.com/licensing/servicelevelagreements) document, versioned by effective date. In every case, the artifact you are bound to is a document the counterparty controls and can revise. #### The revision is a normal publishing event for them Inside the vendor, an SLA revision is a legal decision that ends in a content deployment: review, effective date, push. There is no breaking-change announcement, because nothing broke from their side. Vendors announce API deprecations loudly because customers file tickets when code stops working. Nobody's code stops working when a credit tier moves from 25% to 10%. #### Notice clauses are weaker than people assume, and revisions run one way Enterprise agreements often require notice of material changes to service terms, but "material" is doing enormous work there, and the notice usually arrives as a line item in a bulk terms-update email your legal contact archives. On a standard order form, the page is the notice. Revisions are also not random: a vendor tightening its own exposure lowers a target, narrows the definition of downtime, broadens the exclusions, or shortens the credit-claim window. Those edits are small, legally precise, and easy to miss in a page running several thousand words. The edits that favour you arrive as a blog post, because they are marketing. ### What exactly should you track on an SLA page? Five things carry money or engineering consequence: the uptime percentage, the service credit schedule, the definition of downtime and its exclusions, the claim procedure and its deadline, and the maintenance window language. Everything else on the page is scaffolding. #### The uptime target This is the headline number, and it is rarely a single number. A provider may commit to one percentage for a multi-zone deployment and a lower one for a single instance, as the Amazon Compute SLA does by separating region-level and instance-level commitments. A drop from 99.99% to 99.9% is the difference between roughly four and roughly forty-three minutes of contractually acceptable downtime per month. If your own customer-facing SLA sits on top of the vendor's, that digit can put you underwater on a commitment you already sold. #### The service credit schedule The credit table is where the remedy lives, and it is usually tiered. AWS publishes a schedule under which credits step up as measured uptime falls through defined bands, reaching 100% of affected charges at the worst tier; Microsoft's online services agreement steps credits upward across bands too. Two things move: the percentages, and the thresholds that trigger them. Watch both. A schedule keeping the same percentages while raising the threshold for the top tier is a downgrade dressed as no change. #### The definition of downtime and the exclusion list The most consequential edits are definitional. "Unavailable" might mean total loss of external connectivity, or an error rate above a stated threshold sustained for a stated period. Exclusions typically carve out planned maintenance, customer misconfiguration, force majeure, beta features, and issues originating outside the provider's network. Every line added there shrinks the surface the commitment covers without touching the percentage anyone quotes in a procurement review. #### The claim procedure and deadline Credits are almost never automatic. The page specifies who files, what evidence is required (usually request logs or error rates with timestamps), and a deadline, often measured in days from the end of the billing month containing the incident. If that window shortens while your incident process assumes the old one, you survive the outage and forfeit the remedy on a technicality. #### Maintenance window language Planned maintenance is normally excluded from the uptime calculation, which makes the maintenance definition part of the SLA whether or not it sits under that heading. Watch the notice period, the length and timing of standard windows, and any expansion of what counts as "emergency" maintenance, which is typically exempt from notice entirely. Vendors publishing a maintenance calendar, as Salesforce does on [Salesforce Trust](https://trust.salesforce.com/), give you a second page worth watching alongside the legal text. ### Which vendor SLA pages are worth monitoring first? Start with the vendors whose failure would breach a commitment you have made to your own customers, then add anything with a credit large enough to be worth claiming. For most engineering organisations that is eight to twenty pages: cloud provider, payment processor, identity provider, data platform, and the primary communications and observability vendors. | Tier | What belongs here | Why it ranks here | |------|-------------------|-------------------| | Tier 1 | Cloud compute, storage, networking; payments; identity | Their availability floor sets yours, and credits are large enough to matter on an invoice | | Tier 2 | Data warehouse, queueing, CDN, email delivery, observability | Outages degrade rather than kill the product, but credits are still worth claiming | | Tier 3 | Internal tooling, CI, analytics, secondary SaaS | Little contractual exposure, but terms drift feeds the annual vendor review | #### Cloud, payments, and identity Infrastructure pages carry the most structure and the most money. Google splits its commitments per product across the [Google Cloud SLA directory](https://cloud.google.com/terms/sla), so a team running compute, storage, and a managed database is bound by three documents with three revision histories. Monitor the product pages you depend on, not the index that links to them, because the index rarely changes when a target does. A payment processor's availability commitment sits directly on your revenue, and processors publish availability language inside their service terms, such as those Stripe maintains in its [legal terms directory](https://stripe.com/legal). An identity outage is a total outage for you, however healthy the rest of your stack looks. #### The vendors you resell or pass through If you sell an SLA to your own customers, every upstream commitment feeds a number you already promised, and when an upstream target drops and yours does not, you absorb the difference. So a terms-change alert belongs beside your [cloud status page monitoring](/blog/cloud-status-page-monitoring-aws-gcp-azure-cloudflare): status pages report incidents, SLA monitoring reports the terms those incidents are measured against. ### How is SLA page monitoring different from uptime monitoring? Uptime monitoring measures whether a service is responding right now. SLA page monitoring watches the document defining what "responding" contractually means and what you are owed when it does not. One produces incident data, the other contract intelligence. Most teams run the first and skip the other entirely. The two answer different questions during the same incident. Your uptime tooling says the API returned errors for 47 minutes. The SLA page says whether that qualifies as "Unavailable" under the current definition, which credit band it falls into, and how long you have to file. We cover the broader distinction in [uptime monitoring versus change monitoring](/blog/website-uptime-vs-change-monitoring-differences). | Question | Answered by uptime monitoring | Answered by SLA page monitoring | |----------|-------------------------------|----------------------------------| | Is the service down now? | Yes | No | | Does this outage qualify for a credit? | No | Yes | | Did the target change since we signed? | No | Yes | | Has the claim deadline shortened? | No | Yes | | Is this maintenance window excluded? | No | Yes | Keep a third document in the same folder: the vendor's general terms of service, which usually contains the change-notification clause governing the SLA itself. Our guide to [monitoring terms of service changes at SaaS vendors](/blog/monitor-terms-of-service-changes-saas-vendors) covers that side, and [SaaS API deprecation and sunset notice monitoring](/blog/saas-api-deprecation-sunset-notice-monitoring) covers the engineering-facing announcements alongside both. ### How do you set up SLA change monitoring in PageCrawl? Point a monitor at each SLA document you are bound by, track the main text body rather than the whole page, check daily, and route alerts to the channel where your platform and procurement people already talk. Setup takes a few minutes per vendor and then runs unattended. 1. **Collect the exact URLs.** Open each SLA from the link your contract references, not a search result. Copy the document itself, the per-product page rather than the index listing every agreement. If the vendor publishes a versioned PDF, capture that URL too. 2. **Add each URL as a separate monitor.** One document per monitor keeps the diff readable and lets you set different frequencies per tier. Name them consistently, something like "AWS Compute SLA", so the alert subject tells you what moved before you open it. 3. **Pick the tracking mode.** Reader or content-only tracking extracts the body of a long legal page and ignores navigation, cookie banners, and footers. Where you care about one figure, specific text or number tracking on the uptime percentage keeps the alert narrow. For a versioned PDF, use PDF extraction so the words inside are compared rather than the file wrapper. 4. **Set the check frequency by tier.** A daily check suits Tier 1 vendors, since SLA revisions are not fast-moving events. Higher plans allow checks as often as every 2 minutes, worth it where you want the change logged with a tight timestamp for an audit trail. Alerts arrive when the next check detects the change. 5. **Choose notification channels.** Email, Slack, Discord, Teams, Telegram, and webhooks are all available. Default to a shared Slack or Teams channel containing both platform engineering and whoever owns vendor contracts, since an SLA change needs an engineering read and a commercial read. Webhooks push it into a ticket or a vendor-risk register; our [Slack website change alerts guide](/blog/website-change-alerts-slack) covers that setup. 6. **Add keyword and threshold rules.** A condition such as "alert only when the change contains 99.9, 99.95, 99.99, credit, maintenance, or exclusion" turns a noisy legal page quiet. On a monitor scoped to a single percentage, a numeric threshold rule fires only when the figure moves. 7. **Turn on screenshots and keep the history.** A timestamped capture of the page as it read on a given date is the evidence you want when a vendor's support team and your procurement team disagree about which version applied. 8. **Train out the noise on the first few alerts.** Legal pages carry last-reviewed dates, region selectors, and rotating banners. When one triggers an alert, mark that region as ignored so later checks skip it. ### What do you do when an SLA change alert lands? Read the diff, decide in one pass whether it is cosmetic or substantive, and if it is substantive do three things: record the previous version, check it against your own customer commitments, and check whether your contract lets you object. 1. **Classify the change.** Reformatting, a product added to a covered-services list, and clarified wording that moves no number are cosmetic. Anything touching a percentage, a credit tier, an exclusion, a definition, or a deadline is substantive and needs an owner. 2. **Preserve the prior version.** Your monitoring archive holds the page as it read before the edit, with a timestamp. Attach it to the vendor record. If you later argue your renewal executed against the earlier terms, that is your evidence, and the vendor's own page will no longer show it. 3. **Test it against your downstream promises.** An upstream drop from 99.99% to 99.9% on a dependency in your critical path means the availability commitment you publish to your own customers now rests on redundancy you may not have built. 4. **Check your objection rights and file the diff.** Negotiated agreements sometimes pin the SLA to a version as of the effective date, or give you a window to object to material changes, and that right is worthless if you learn of the change eleven months later. Either way the dated diff goes into the renewal file: a vendor that has weakened its commitment twice since you signed is a different counterparty from the one you evaluated. ### What goes wrong when monitoring SLA pages? Three things: legal pages are noisy in ways that trigger meaningless alerts, some vendors move the document instead of editing it, and a change alert only helps if it reaches someone who can act commercially rather than only technically. #### Boilerplate noise A vendor legal page carries a last-updated stamp, a cookie consent block, a locale switcher, a chat widget, and a footer of rotating links. Any of those can change without a word of the agreement changing. Scope the monitor to the document body with reader or content-only tracking, and mark the remaining offenders as ignored regions after the first couple of alerts. A well-tuned SLA monitor is silent for months. #### Relocated and superseded documents Vendors sometimes publish a new SLA at a new URL and leave the old one in place, or redirect a page to a consolidated terms document. A monitor on a stale URL sits quietly forever while the real terms change elsewhere. Two habits fix this: monitor the vendor's legal index alongside the specific document, so a newly listed agreement shows up, and treat a redirect or a "superseded" notice as high priority rather than noise. #### PDFs and effective-date versioning Some vendors, Microsoft among them, publish the authoritative SLA as a dated document rather than a rolling web page. The signal there is a new effective date appearing on the index, not an edit to the text you already hold. Monitor the page listing current versions, and use PDF extraction on the document so the comparison happens on words rather than the file. #### The alert reaching the wrong desk An SLA change is half engineering, half commercial. Sent only to a platform channel it reads as trivia; sent only to procurement, the availability implications are missed. Route it where both audiences see it, or use a webhook to open a ticket with two named reviewers. ### Choosing your PageCrawl plan PageCrawl's **Free plan** lets you monitor **6 pages** with **220 checks per month**, which is enough to validate the approach on your most critical pages. Most teams graduate to a paid plan once they see the value. | Plan | Price | Pages | Checks / month | Frequency | |------|-------|-------|----------------|-----------| | Free | $0 | 6 | 220 | every 60 min | | Standard | $8/mo or $80/yr | 100 | 15,000 | every 15 min | | Enterprise | $30/mo or $300/yr | 500 | 100,000 | every 5 min | | Ultimate | $99/mo or $999/yr | 1,000 | 100,000 | every 2 min | Annual billing saves two months across every paid tier. Enterprise and Ultimate scale up to 100x if you need thousands of pages or multi-team access. At an engineering hourly rate, Standard at $80/year pays for itself the first time you catch a breaking API change, a deprecated endpoint, or a silent config change before it takes down production. 100 monitored pages is enough to cover the changelogs and docs of every third-party API your stack depends on. Enterprise at $300/year adds higher check frequency, 500 pages, and full API access. All plans include the **PageCrawl MCP Server**, which plugs directly into Claude, Cursor, and other MCP-compatible tools. Developers can ask "what changed in the Stripe API docs this month?" and get a summary pulled from your own monitoring history. AI assistants can create monitors through conversation on every plan, including Free, turning your tracked pages into a living knowledge base instead of a pile of alert emails. ### Getting Started Open your three largest vendor invoices and find the SLA each contract points at. Those three URLs are your first monitors, and they fit inside the free tier with room left over. Set each to reader or content-only tracking on a daily check, route alerts to a channel containing both an engineer and whoever signs the renewals, and let the first week train out the timestamp noise. Then work down the list, cloud to payments to identity to data platform, until every vendor whose availability floor sets yours is covered. The next time a credit tier moves, be the party that noticed. Set up the first monitor today and stop discovering your own commitments during a postmortem. --- Need more? The complete PageCrawl.io help center, with every article, is available as a single document at https://pagecrawl.io/llms-full.txt. Read it for context on anything this page does not cover.