Workflow Orchestration SLA Credits: Step Functions, Logic Apps, Workflows and Cloud Tasks
October 24, 2026
Your orchestration service can be down for an hour and your SLA credit is zero, because these SLAs measure the API, not your workflow. Step Functions, Logic Apps, Workflows and Cloud Tasks all promise 99.9% or better, but each one defines "down" differently, and the definitions decide whether a failed run earns you anything. Here are the exact tiers, measurement rules, deadlines, and the math on real bills.
The pattern: they measure the control plane, not your runs
Every orchestration SLA in this family shares one trait: the credit is tied to the API calls that start, stop, or manage a workflow, not to whether your workflow completed. A Step Functions state machine that hangs because a downstream Lambda is slow is not a breach. A Logic App that fails because a connector returned a 4xx is not a breach. The provider owes you only when its own control plane fails to accept or process your requests.
That distinction is why most orchestration outages never produce a claim: the failure is usually in your code, your dependencies, or your configuration, and the SLA excludes all three.
| Service | Commitment | Downtime definition | Credit tiers |
|---|---|---|---|
| AWS Step Functions | 99.9% | Requests returning 500/503 per 5-min interval; empty intervals count 100% available | 10% / 25% / 100% |
| Azure Logic Apps | 99.9% | No connectivity between the app and Microsoft's Internet gateway, per Deployment Minute | 10% / 25% |
| Google Workflows | 99.9% | More than 10% error rate over 60+ consecutive seconds, min 100 valid requests | 10% / 25% / 50% |
| Google Cloud Tasks | 99.95% | No CreateTask request succeeds for 60+ consecutive seconds, under 1,000 ops/sec | 10% / 25% / 50% |
The one rule that decides whether an orchestration outage pays: the SLA measures the control plane API, not your workflow. If your run fails because of your code, your dependencies, or your configuration, the credit is zero. Only a provider-side failure of the API itself counts.
AWS Step Functions: 99.9%, and the $1 floor bites
Step Functions commits to a 99.9% Monthly Uptime Percentage per region (SLA last updated May 5, 2022). Availability is calculated per 5-minute interval as the share of requests that do not fail with an Error, where an Error is any request returning a 500 or 503. If you made no requests in an interval, that interval is assumed 100% available. A quiet night with no executions cannot drag the number down; a burst of traffic during a partial outage is what breaches the tier.
The credit ladder is the standard AWS shape: 10% below 99.9%, 25% below 99.0%, 100% below 95.0%. Credits apply only to Step Functions charges for the affected region in that billing cycle, and only if the credit is greater than $1. That floor is the trap. Step Functions bills $0.000025 per state transition after a 4,000-transition free tier. A modest workflow that runs 100,000 times a month with four transitions costs about $9.90. A 10% credit on that is 99 cents, under the $1 floor, so you get nothing.
To file, open an AWS Support case with "SLA Credit Request" in the subject, including the billing cycle, region, Monthly Uptime Percentage, the dates and times of each 5-minute interval below 100% availability, and request logs documenting the errors. The claim must arrive by the end of the second billing cycle after the incident; credits issue within one billing cycle of confirmation.
Azure Logic Apps: 99.9%, but only 10% and 25% tiers exist
Logic Apps commits to 99.9% uptime in the October 2026 Microsoft consolidated SLA, and the credit schedule stops at 25%. There is no 100% tier, so even a catastrophic month caps your recovery at a quarter of the Logic Apps bill.
The measurement is unusual. Downtime is defined as minutes where there is no connectivity between the Logic App and Microsoft's Internet gateway, accumulated across all Logic Apps in a subscription and divided by Maximum Available Minutes, the sum of all Deployment Minutes. A Deployment Minute only counts while the app is set to running, so a stopped app neither adds to the denominator nor dilutes the numerator. The SLA covers connectivity to Microsoft's network, not the success of any action, trigger, or connector call.
Credits are 10% below 99.9% and 25% below 99.0%. Claims must be received within 60 days of the incident, and for metered pay-as-you-go services the Applicable Period is the 30 days before and including the first day of the incident. Microsoft processes claims typically within 45 days of receipt. One more trap: Logic Apps deployed into an Integration Services Environment lost all SLA guarantees when ISE was retired on September 1, 2024.
Google Workflows: 99.9% on four API operations
Google's Workflows SLA (last modified December 6, 2021) covers exactly four operations: CreateWorkflow, PatchWorkflow, CreateExecution, and CancelExecution. Downtime is more than a 10% error rate, the share of valid requests returning a 500-range status, with a minimum of 100 valid requests in the measurement period. A Downtime Period requires 60 or more consecutive seconds; blips under a minute do not count.
The credit ladder is 10% between 99% and 99.9%, 25% between 95% and 99%, and 50% below 95%, with a hard cap: the maximum aggregate credit for a month is 50% of the Workflows bill. You must notify Google technical support within 30 days of becoming eligible, and credits are applied within 60 days of the request. Measurement is per project per region.
The money is small unless you run heavy volume. Workflows charges $0.01 per 1,000 internal steps and $0.025 per 1,000 external steps, after free allowances of 5,000 and 2,000 steps. A workflow doing 1 million internal steps a month costs about $10, so a 10% credit is $1. The 30-day window is the real cost: miss it and the credit is forfeited.
Google Cloud Tasks: 99.95%, the tightest promise here
Cloud Tasks (SLA last modified June 22, 2021) commits to 99.95% for the CreateTask operation, the tightest SLO in this family. Downtime means no valid CreateTask request succeeds, measured server-side, for 60 or more consecutive seconds, and only while total task operations to a single queue stay below 1,000 operations per second over the trailing hour. Above that rate, the SLA stops applying to that queue.
Credits are 10% between 99% and 99.95%, 25% between 95% and 99%, and 50% below 95%, with the same 50% monthly cap and the same 30-day notification window. Pricing is $0.40 per million billable operations after a free million, so a queue pushing 10 million tasks a month costs $3.60. A 10% credit is 36 cents. The SLA is real, but the credit is pocket change unless you run at serious scale.
The money math: what an outage actually pays
The credit is a percentage of the orchestration bill, not of the workloads it orchestrates. That is the sentence most people miss. An 8-hour Step Functions outage that stalls a pipeline moving $50,000 of orders pays 25% of your Step Functions spend, which might be $25, not 25% of the orders.
| Scenario | Monthly orchestration bill | Outage | Month uptime | Credit | Payout |
|---|---|---|---|---|---|
| Step Functions, 10M transitions/mo | $250 | 45 min | 99.90% | 10% | $25 |
| Step Functions, 10M transitions/mo | $250 | 8 hours | 98.89% | 25% | $62.50 |
| Step Functions, 400K transitions/mo | $9.90 | 8 hours | 98.89% | 25% | $2.48, but $1 floor applies, paid |
| Logic Apps, 1M action executions/mo | $200 | 8 hours | 98.89% | 25% | $50 |
| Workflows, 1M internal steps/mo | $10 | 8 hours | 98.89% | 25% | $2.50 |
| Cloud Tasks, 10M tasks/mo | $3.60 | 8 hours | 98.89% | 25% | $0.90 |
The 8-hour row is identical across providers: 480 minutes out of a 43,200-minute month is 1.11%, putting the month at 98.89%, below the 99.0% boundary that triggers the 25% tier on every ladder. The difference is the base. Orchestration services are cheap, so credits are small, but the claim is still worth filing when the bill is real: one support ticket, and the evidence is usually already in your logs.
What evidence survives a claim
Each provider wants the same four artifacts, in slightly different wrappers:
- The incident window in UTC, with the specific intervals where requests failed.
- Your request logs showing 500 or 503 responses (AWS), or failed CreateTask/CreateExecution calls (Google), or connectivity loss (Azure).
- The affected resource identifiers: state machine ARNs, Logic App names, project and region, queue names.
- The provider's own incident record, if one exists, to corroborate the window.
AWS disqualifies a claim if the required information is missing. Google forfeits the credit if you do not notify support within 30 days of eligibility. Azure rejects claims that lack the incident description, time and duration, affected resource names, affected users, and a description of errors. Collect the logs before the month rolls over: the AWS window is tied to the billing cycle, the Google window to eligibility, and both are shorter than they feel.
The one thing to do today
Pick the orchestration service that carries your most important business process and check which of its API operations the SLA actually covers. For Step Functions that is StartExecution and StartSyncExecution. For Workflows it is CreateExecution and CancelExecution. For Cloud Tasks it is CreateTask. For Logic Apps it is connectivity, not actions. If your critical path depends on anything outside those operations, the SLA will not pay for it, and that is the gap to close with your own monitoring and runbook, not with a credit claim.