Vicedomini Softworks

Software Development

Custom Software SLA: 8 Components Engineers Can Enforce

24 September 2026

Decorative watercolor title card for software SLA

An SLA for a software application is a contractual definition of measurable service commitments, typically availability, latency and support response times, designed to align expectations between provider and client. It gives both sides a shared, enforceable baseline instead of vague assurances. When targets are missed, the SLA sets out remedies, usually service credits, and the process for claiming them.

TL;DR:

  • SLAs must include clear scope, definitions, specific metrics and targets, measurement methods, reporting schedules, remedies, exclusions, and client responsibilities.
  • Availability SLAs typically measure successful requests over total requests monthly, with latency expressed as percentile thresholds to account for worst-case performance.
  • Exclusions such as scheduled maintenance, force majeure, or client misconfigurations can significantly weaken SLAs if not explicitly defined or accounted for in the agreement.
  • Monitoring should be automated and continuous, with error budgets guiding release pauses and reliability focus, and claims require time-stamped evidence submitted promptly.
  • Setting realistic, achievable SLOs at the start and gradually tightening targets based on operational data enhances reliability without hampering development progress.
Vicedomini Softworks
Build Reliability Into Your Software
Vicedomini Softworks helps organizations engineer secure, observable software with ongoing support aligned to long-term business objectives.
Explore software engineering

Table of Contents

What SLA, SLO and SLI actually mean for a software application

These three terms get used interchangeably, which causes real confusion at contract-drafting stage. The SLA is the external, often legally binding, contract between provider and client. It states what will be delivered and what happens if it isn’t. The SLI (service level indicator) is the raw metric being measured, request success rate, response time, error count, that feeds the SLO.

The relationship matters because an SLA should never promise more than the underlying SLOs can reliably deliver. This is where the error budget becomes useful: subtract the SLO from 100% and you get the tolerable failure rate before engineering must stop shipping features and focus on reliability instead. A 99.9% SLO leaves an error budget of 0.1%, which sounds tiny until you realise it still permits 1,000 failed requests per million.

  • SLA: the contractual promise, with remedies attached
  • SLO: the internal target the SLA is built on
  • SLI: the measured data point behind the target
  • Error budget: the permitted failure margin before reliability work takes priority

Which metrics belong in a software application SLA

Availability is the metric everyone reaches for first, and it’s usually calculated as successful requests divided by total requests over a defined window, typically monthly. The Atlassian definition of an SLA centres on exactly this kind of uptime and response-time commitment, paired with remedies when targets slip.

Latency deserves more nuance than a single average figure. A single number hides long-tail pain, so mature SLAs specify multiple percentile thresholds, for example 90% of requests under 100 milliseconds and 99% under 400 milliseconds, an approach Google’s SRE workbook recommends to capture both typical and worst-case experience.

A monthly availability SLO of 99.9% permits a small amount of downtime each month, reflecting realistic tolerance for service interruptions. That single fact reshapes most negotiations, because clients often assume “99.9%” means near-zero disruption.

  • Availability: successful requests over total requests, aggregated monthly or quarterly
  • Latency: percentile-based thresholds (p90, p95, p99), not a single average
  • Error and correctness rates: essential for pipelines, integrations and transactional systems
  • Support metrics: acknowledgement time, resolution time, business-hours definition, escalation contact
  • Exclusions: scheduled maintenance and client-caused faults must be written into the metric definitions, not left implicit

Drafting an SLA: checklist and template skeleton

A workable SLA needs eight components. Missing any one of them tends to produce disputes later, usually at the worst possible moment, mid-incident.

  1. Scope: which application, environments and user-facing functions are covered
  2. Definitions: precise wording for “downtime”, “incident” and “business hours”
  3. SLIs and SLOs: the specific metrics and their numeric targets
  4. Measurement method: how data is captured, from which monitoring source, over what window
  5. Reporting cadence: monthly or quarterly reports, delivered by whom and to whom
  6. Remedies and credits: the credit scale tied to specific breach severity
  7. Exclusions: maintenance windows, force majeure, third-party outages, client misconfiguration
  8. Preconditions: client responsibilities, such as implementing retry logic, that must be met for the SLA to apply

A compact template skeleton might read: *"Provider guarantees [X]% monthly availability for [service], measured as successful HTTP responses over total requests, excluding scheduled maintenance under four hours notified 48 hours in advance.

Before signing, verify:

  • Monitoring and alerting are already instrumented, not promised for later
  • Runbooks exist for the incidents the SLA covers
  • Escalation contacts are named individuals, not generic inboxes
  • Observability covers every dependency the SLA implicitly relies on

Common exclusions and gotchas that weaken SLAs

Many SLAs look generous until you read the exclusions clause. Scheduled maintenance windows, force majeure and client misconfiguration are standard carve-outs, and reasonably so, but the detail is where risk hides. Microsoft’s guidance on interpreting SLAs points out that many agreements are conditional: they apply only when specific preconditions, like retry logic or a particular deployment topology, are actually implemented by the client.

Aggregation periods can also mask reality.

  • Watch for vague “downtime” definitions that exclude partial degradation
  • Check whether the SLA covers every endpoint, or only a subset
  • Confirm who is responsible for retry logic and failover behaviour
  • Ask whether preview or beta features are silently excluded

Pro Tip: *Set your internal SLOs tighter than the contractual SLA.

Running SLAs day to day: monitoring, error budgets and claims

An SLA only earns its keep once it’s operational, not just signed. That means automated pipelines feeding dashboards and alerting from real SLIs, not spreadsheets updated after the fact. Error budget policies then give teams a decision rule: when the budget is nearly exhausted, feature releases pause and reliability work takes priority, a discipline Google’s SRE practice formalises well.

Claims processes need the same rigour. Evidence of breach, timestamps, affected requests, root cause, usually has to be documented and submitted within a fixed window, often 30 days, or the credit simply lapses.

  • Automate SLI collection; manual tracking degrades within weeks
  • Set explicit error budget thresholds tied to release decisions
  • Log evidence continuously, don’t reconstruct it after an incident
  • Use SLA reports to spot capacity gaps, not just to assign blame

Teams operating SaaS products at scale often lean on structured rollout playbooks, such as this approach to launching SaaS without heavy internal IT overhead, to keep monitoring and reporting consistent as the product grows.

How Vicedomini Softworks turns SLA commitments into engineering practice

Realistic SLOs get set at discovery, not after launch, when the client talks directly with the engineers who will build the system rather than through an account manager relaying requirements second-hand. That direct line tends to surface which availability targets are actually achievable given the architecture on the table, before a number gets written into a contract it can’t support.

The operational side follows a recognisable pattern: instrumentation built in from day one, runbooks for known failure modes, automated tests, and periodic resilience checks rather than assumptions. Ask any development partner for proof, not promises.

  • Request live dashboards, not static reports
  • Ask to see runbooks for the top three failure scenarios
  • Confirm code review practices, peer review should be standard, not optional
  • Get the deployment topology in writing before agreeing SLO numbers

A pragmatic view on reliability targets

It slows delivery, inflates cost and rarely reflects what users actually need. The smarter move is setting an honest SLO, tracking the error budget, and tightening the number gradually as the system proves itself. The same discipline applies to third-party dependencies: negotiate their SLAs with the same scepticism you’d apply to your own, because a provider’s uptime percentage rarely maps cleanly onto your application’s reliability. Used well, an SLA isn’t a punishment clause. It’s a trust mechanism that gets sharper with every review cycle.

— Pepe F.

Get help drafting and operating an SLA that actually holds up

Vicedomini Softworks approaches SLA work the way it approaches every engagement: engineers talk to you directly, not through a layer of account management, so the availability and latency targets you agree to are grounded in what your architecture can genuinely support.

Vicedomini Softworks

That direct-access model maps neatly onto the services SLA work actually needs. An initial assessment typically surfaces where current monitoring falls short and which SLOs are realistic before you commit to numbers in writing. From there, CTO Advisory offers ongoing architecture and SLA review services, while custom software development and code audit services cover the instrumentation, runbooks and observability work an SLA depends on operationally. If you’re negotiating an SLA for a new build or reviewing one that’s already underperforming, book an initial assessment and get a written recommendation before you sign anything.

Primary sources for further reading

Primary sources for further reading — overview diagram

Key references: Google SRE error budget policy, ISO/IEC 20000-1 service management standard, and Atlassian’s SLA best practices.

Sources

FAQ

What is an SLA in computing?

An SLA in computing is a formal agreement between a service provider and a customer that sets measurable performance targets, such as uptime and response times, along with remedies when those targets aren’t met, as described in Atlassian’s SLA guidance.

What are SLA services exactly?

SLA services refers to the specific commitments a provider guarantees, such as application availability, support response times or resolution windows, rather than a separate product category. They’re the measurable promises embedded inside a broader service contract.

What does SLA mean in practice?

SLA stands for service level agreement, a document that translates operational targets into contractual language with defined consequences for missing them. It exists to manage expectations and provide an enforceable basis for compensation, per IBM’s overview of SLAs.

What’s the difference between a KPI and an SLA?

A KPI is an internal performance indicator used to track how well a team or system is doing, without necessarily carrying contractual weight. An SLA is the external, often binding, agreement that turns specific KPIs, like availability or response time, into commitments with remedies attached when they’re breached.

How do you claim SLA credits after a breach?

Claiming credits usually requires documenting the breach, timestamps, affected requests and root cause, and submitting it within a fixed deadline set by the contract, often around 30 days. Missing that window typically means forfeiting the credit, so understanding the preconditions in advance matters more than reacting after the fact.