Not a Microsoft-bashing post. The SLA is a published, contractual mechanism — using it properly is just being a grown-up customer. This post was created with the help of AI.
The one distinction that matters
The business measures lost orders. Microsoft measures the incident against a contractual definition of downtime. A broken customer journey is not automatically an SLA breach.
So the only real question during an outage: was this a covered failure in Microsoft’s Commerce platform, or something on our side of the line? Honest answer from the field — a lot of the time it’s ours. Custom code, a deployment or capacity. Knowing which is which is the whole job.
What counts, what doesn’t
Under the August 2026 Microsoft Online Services SLA, qualifying downtime is when end users can’t access the active tenant because of a failure in the D365 Commerce platform or Microsoft-managed infrastructure — validated by Microsoft’s own monitoring and logs. You also need an active, highly available production topology with sufficient reserved capacity to qualify at all.
Excluded: scheduled downtime, add-on features, your own modifications, exceeded Commerce Scale Unit capacity, unsupported configurations, your network, third-party services, previews/trials, and slow-but-available performance.
| What the customer experienced | Likely relevance |
|---|---|
| Storefront erroring — Microsoft rendering platform down | Strong candidate |
| Commerce Scale Unit APIs down — Microsoft platform failure | Strong candidate |
| Auth fails because covered Microsoft infrastructure failed | Potentially qualifying |
| Checkout fails only because your PSP is down | Normally outside the SLA |
| Custom checkout module breaks after your deploy | Likely excluded |
| Site slow but available | Not downtime |
| CSU capacity exceeded | Specifically excluded |
| Scheduled maintenance window | Normally excluded |
Checkout incidents are the hard ones — customers browse fine but can’t buy. Name the exact Commerce API that failed. A screenshot of a sad checkout page is weak; timestamped API errors are strong.
Do this before you need it
Find your SLA now. Microsoft normally applies the version current when the subscription started or renewed — the newest doc online may not govern you. Note the tenant, environments, CSUs, whether Microsoft or a CSP invoices you, and who internally owns filing a claim.
Monitor the whole journey, not the home page. A site happily returns HTTP 200 while nobody can buy. Synthetic tests should walk: home → category → search → product → price/inventory → add to basket → checkout → delivery → payment. Keep status codes, failed Commerce API calls, correlation IDs, CSU endpoints, traces, timestamps. Extension telemetry can flow to Application Insights. Set it up on a calm Tuesday 😊
During: timeline in UTC
First confirmed failure, last good transaction, affected channels/markets/CSUs, sessions and orders lost, exact errors, recent deployments, restoration time, first good transaction after.
Check the authenticated Service health experience and save the incident ID and every update. An incident notification is good evidence — but it is not confirmation the SLA was missed; the SLA separates outage comms from credit eligibility.
Open a production support incident via Lifecycle Services/PPAC. Restoration first. But note: the technical ticket does not become an SLA claim on its own. After restoration, create a new ticket with the words — “Dynamics 365 Commerce SLA service-credit claim”.
The maths and the money
Uptime uses user-minutes, not wall clock: (total user-minutes − downtime user-minutes) ÷ total × 100. A full outage hitting everyone needs roughly 43.2 minutes in a 30-day month to drop below 99.9%.
| Uptime | Credit |
|---|---|
| Below 99.9% | 25% |
| Below 99% | 50% |
| Below 95% | 100% |
That’s a percentage of eligible Commerce service fees — not lost sales, not Azure, not your whole invoice, and not the services you receive from your partner. Manage expectations before finance starts dreaming 😊. It will be a very small sum!
Direct customers file with Microsoft support; CSP customers file with whoever invoices them (Partner Center guidance), and CSP deadlines are often earlier. Claims are generally due by the end of the period following the incident month — 15 February incident, 31 March deadline — and are typically processed within 45 days.
The bit I actually care about
Run two measures: a business SLO for the full shopping journey, and the Microsoft SLA for eligible platform failures. The first tells you if the store is making money. The second tells you if part of the fee comes back.
The credit is rarely the point. Good monitoring and a clean UTC timeline is what turns a frustrated complaint into a credible conversation — and makes you faster at fixing the outages that are yours. Which is most of them.
Operational guidance, not legal advice — check the SLA that applies to your subscription.