📝 Writing SLA Language

99.99% uptime (four nines) is the appropriate tier for payment processing.

Why not 99% or 99.9%?
• 99% allows ~7.3 hours/month of downtime — for a payment API, that's potentially thousands of failed transactions per hour. Totally unacceptable for enterprise clients.
• 99.9% allows ~43.8 minutes/month — still too high for a critical financial path. Most enterprise payment contracts require better than this.

Why not 100%?
100% uptime is not achievable in practice — hardware fails, networks partition, deployments require restarts. Never put 100% uptime in an SLA. Even the most sophisticated hyperscalers (AWS, Google Cloud) do not offer 100% SLA commitments. A 100% uptime clause:
• Exposes you to unlimited liability for any fleeting disruption
• Is contractually unenforceable as written
• Signals engineering naivety to sophisticated buyers

Industry standard for payment processing: 99.99% (four nines) = ~52.6 minutes/year. This is the baseline expectation in PCI-DSS environments and enterprise payment contracts.

The correct clause pattern: "[Availability %] of the time in any [calendar month / rolling 30-day period]" + the specific downtime calculation demonstrates you understand the commitment you're making.

"Initial response within 15 minutes, status update every 30 minutes, target resolution within 4 hours."

A well-written SLA incident response clause has three distinct commitments:

① Initial response time — how quickly someone acknowledges the incident ("15 minutes"). This is the hardest commitment because it means the on-call engineer must be available 24/7.
② Communication cadence — how often stakeholders receive updates while the incident is active ("every 30 minutes"). This is crucial: customers want to know you're working on it, even if there's no resolution yet.
③ Target resolution time — how long until the service is restored ("4 hours"). Note: this is usually a target, not a hard guarantee, because incident complexity varies.

Why "as quickly as possible" is bad SLA language:
"As quickly as possible" is not a commitment — it's a statement of intent. It sets no measurable obligation and cannot trigger any service credit or contractual consequence. Clients cannot plan around it.

Why "24/7/365 support" isn't enough:
This states availability, not response speed. "Available" and "will respond in 15 minutes" are very different commitments.

Pattern to know: P1 → 15 min / P2 → 1 hour / P3 → 4 hours / P4 → 1 business day is a common SLA tiering structure.

The SLA was breached. 135 minutes of downtime exceeded the 43.8-minute monthly allowance.

The maths:
• Monthly minutes: 30 days × 24 hours × 60 min = 43,200 minutes
• 99.9% uptime → 0.1% allowed downtime = 0.001 × 43,200 = 43.2 minutes/month
• Actual downtime: 2h 15min = 135 minutes
• Breach: 135 − 43 = 92 minutes over budget

Why option C is wrong: SLAs are typically measured per calendar month (or per rolling 30-day period), not annually. Even if the annual budget (8.76 hours/year) appears to have remaining headroom, a 2h15min incident in a single month still breaches the monthly commitment.

Why "users affected" is irrelevant to availability SLAs: Standard uptime SLAs are measured by service availability, not the number of users impacted. Separate clauses may address data loss or degraded performance for specific user counts, but availability is binary: up or down.

Writing an SLA breach notification:
"Our service availability for November fell to 99.69%, below our committed 99.9% SLA. Total unplanned downtime: 135 minutes (SLA allowance: 43 minutes). We will apply service credits as outlined in Section 4.2 of your contract."

$1,500 — 10% × $5,000 × 3 hours = $1,500. And the 30% cap ($1,500) doesn't reduce it further.

The calculation:
① Per-hour credit: 10% of $5,000 = $500 per hour of excess downtime
② Total excess downtime: 3 full hours
③ Credit: $500 × 3 = $1,500
④ Maximum cap: 30% of $5,000 = $1,500
⑤ Result: $1,500 (the calculation and the cap arrive at the same number here)

Key SLA credit vocabulary:
• "Service Credits" — also called "SLA credits" — financial compensation deducted from the next invoice; not a cash refund
• "for each full hour" — partial hours don't count; if excess downtime was 3h 45min, only 3 full hours are counted
• "up to a maximum" — a liability cap; protects the vendor from unlimited credit exposure
• "exceeding the SLA threshold" — credits only apply to time above the contractual allowance; the first 43 minutes of downtime in a 99.9% SLA month don't count

Tip: Service Credits are not refunds. They reduce future invoices. Always check whether credits auto-apply or require a formal written claim within a defined window (e.g., "Customer must request credits within 30 days of the incident").

Option B is the only professionally written, complete SLA tier description.

Why it works: A well-written SLA tier description must be:

① Specific and measurable: "P1 initial response: 15 minutes" is a commitment. "Try our hardest" (option A) is not.
② Comprehensive: Lists all components — availability %, response times, support channels, account management, review cadence. Tier descriptions need to tell clients exactly what they're paying for.
③ Consequences stated: "Service Credits apply for any breach" — tells the customer what happens when you miss the commitment
④ Named format: Starting with a bold tier name followed by a structured list is the industry standard format for SLA tier documents

Why option A fails: "Best support", "try our hardest", "as quickly as we can" — all of these are subjective and unenforceable. This is marketing copy, not an SLA.

Why option D fails: "Always resolved within 1 hour" for P1 incidents is an unrealistic guarantee that most organisations cannot meet. And "full money-back guarantee" suggests a full refund of all fees — courts and procurement teams will scrutinise this; it creates enormous financial exposure.

Key elements of a complete SLA tier description:
• Uptime commitment (%)
• Response time by severity (P1/P2/P3...)
• Support hours (business hours / 24×7)
• Channel (phone / email / dedicated Slack)
• Account management (shared CSM / dedicated CSM)
• Review frequency
• Credit/remedy clause reference

David's message correctly identifies a potential issue. However, it lacks specific instructions for escalation. Option 1 aligns with standard practice – investigating and monitoring is key, focusing on root cause. Options 2 & 3 are too reactive; simply notifying or escalating immediately without investigation isn't effective. Option 4 is overly aggressive and doesn't reflect a tiered support approach.

The developer needs to acknowledge the issue and demonstrate action. Option 1 directly addresses the reviewer's concern. Options 2 and 3 dismiss the feedback or offer an inadequate justification. Option 4 is incorrect – console logging *can* impact performance if not managed correctly, a key consideration for SLAs.

The PR description needs to explicitly state adherence to SLA requirements. Option 1 simply lists a technical change without context. Option 3 directly addresses this concern by highlighting minimal disruption and compliance with SLAs. Options 2 and 4 are too focused on the technical details and don't acknowledge the impact on service availability, which is critical for SLAs.

Sarah's response clearly identifies the impact – reporting delays – directly linking it to the SLA. Option 1 downplays the issue. Option 3 is too vague and doesn't quantify the impact. Option 4 shifts the focus from the SLA consequence to performance improvement alone.

This response accurately describes the technical nature of the error (transient fault) and provides a brief explanation. This level of detail is crucial for SLA reporting – documenting the *cause* of the unavailability allows for proper categorization and tracking. Options 1 & 3 are too simplistic; option 4 is incorrect as the API *was* unavailable.