SLI, SLO, and SLA Explained

By Kokil Thapa | Last reviewed: September 2026

Your checkout works in staging, but payments fail twice a week in production. The team argues about whether the site is "down enough" to matter. That confusion is exactly why SLI, SLO, and SLA explained in plain terms saves projects. These three concepts turn vague reliability talk into numbers you can measure, targets you can hit, and contracts you can defend. If you run a production web application, booking portal, or API, you already have implicit promises to users. SLIs make those promises visible. SLOs give your team a shared goal. SLAs formalise what happens when you miss it.

What is the difference between SLI, SLO, and SLA?

The three terms stack together but serve different audiences. Confusing them leads to over-promising in contracts or under-investing in reliability engineering.

An SLI (Service Level Indicator) is a quantitative measure of one aspect of service behaviour. It answers: "How is the system performing right now?" Examples include the ratio of successful HTTP 2xx/3xx responses, checkout completion rate, or queue job success rate.

An SLO (Service Level Objective) is a target range for an SLI over a time window. It answers: "What good enough looks like for our team." Example: 99.5% of checkout requests succeed over a rolling 30-day period.

An SLA (Service Level Agreement) is a business contract with a customer. It states what you guarantee, how you measure it, and what remedy applies if you fail. Example: 99.9% monthly API availability or the client receives a service credit.

Think of it like a speedometer, speed limit, and traffic law. The SLI is your current speed. The SLO is the limit your team agrees is safe. The SLA is what you told the public you would obey.

A critical rule: your SLO should be stricter than your SLA. If your internal target is 99.5% availability but your SLA promises 99.9%, you will breach contracts before your alerts fire. I've seen this on client projects where sales signed uptime guarantees the engineering team never tracked.

For deeper SRE context, read the companion piece on site reliability engineering, SLOs, SLIs, and error budgets. The Google SRE workbook also formalises this model in Google's SLO implementation guide.

How do you choose meaningful SLIs for a web application?

Not every metric deserves SLI status. CPU usage is an indicator of load, not user happiness. Good SLIs reflect what users actually experience.

Start with user journeys, not dashboards. On a booking site like Adventure Third Pole Trek, critical paths include search, availability check, payment, and confirmation email. On a legal portal, document upload and payment collection matter most. Each journey suggests one or more SLIs.

Availability SLIs

Availability measures whether your service responds successfully. For HTTP services, a common formula is:

availability = successful_requests / valid_requests

valid_requests = all requests excluding client errors (4xx you did not cause)
successful_requests = 2xx and acceptable 3xx responses

Exclude deliberate 404s from marketing campaigns. Include 502/503/504 from your load balancer as failures. This distinction matters for API development where clients send malformed payloads constantly.

Latency SLIs

Latency SLIs track how fast requests complete. Do not use average response time alone. Averages hide tail latency that frustrates users.

Use percentiles instead. A practical SLO might require 95% of checkout requests to finish under 800 ms over a rolling week. Prometheus histograms and OpenTelemetry traces both support percentile calculations. See the Prometheus histogram documentation for bucket design guidance.

Correctness and freshness SLIs

Correctness covers business logic outcomes: payment captured, email sent, webhook delivered. Freshness applies to data pipelines: "exchange rates updated within 15 minutes" on a site using the Nepal forex rates tool pattern.

On production Laravel applications I maintain, I often define SLIs at three layers:

1. Edge: Nginx/Apache access logs — status codes and TTFB.
2. Application: Laravel middleware timing, queue job success, failed job rate.
3. Business: Orders completed, documents uploaded, bookings confirmed.

The guide to defining meaningful SLIs and SLOs walks through this journey-first approach in more detail.

How do you set realistic SLO targets?

Setting SLOs is a product decision disguised as an engineering task. Higher targets cost more to achieve. Lower targets risk user trust.

Start with historical data. Pull 90 days of availability and latency from your monitoring stack. If you have nothing, instrument first and wait. Guessing 99.99% on a Rs 5,000/month (~USD 37) shared host is fantasy.

The nines math that actually matters

Each "nine" shrinks allowed downtime dramatically:

• 99% — ~7.2 hours downtime per month
• 99.9% — ~43 minutes per month
• 99.95% — ~22 minutes per month
• 99.99% — ~4.3 minutes per month

For a small Nepali business site with one developer handling dev and ops, 99.5% to 99.9% is often realistic. Enterprise SaaS with redundant infrastructure might target 99.95%. Payment gateways and core banking push higher, but that requires investment most SMB sites cannot justify.

Multi-window, multi-burn-rate alerting

A single monthly SLO is too slow for operations. Pair it with shorter windows for alerting. Google's approach uses burn rates: how fast you consume your error budget.

Example SLO definition in plain language:

99.5% of POST /api/bookings requests return success within 30 days, measured at the load balancer.

Alert when you burn 10% of the monthly budget in 6 hours. That gives time to respond without paging on every blip. The article on SLO-driven alerting that does not page at 3 a.m. covers burn-rate thresholds in practice.

# Example Prometheus recording rule concept
# good_requests / total_requests over 30d window

- record: sli:booking_success:ratio30d
  expr: |
    sum(rate(http_requests_total{route="booking",status=~"2.."}[30d]))
    /
    sum(rate(http_requests_total{route="booking"}[30d]))

- alert: BookingSLOBurnFast
  expr: |
    (1 - sli:booking_success:ratio6h) > (1 - 0.995) * 14.4
  for: 5m
  labels:
    severity: page

Tune the multiplier (14.4 in this example) to match your risk tolerance. Validate rules with the regex tester when parsing log labels, and use the JSON formatter to inspect alert payloads during setup.

How should SLAs differ from internal SLOs?

SLAs exist outside your codebase. They appear in MSAs, hosting contracts, and API terms of service. Treat them as a business instrument, not a monitoring config.

Always leave headroom between SLO and SLA. A common pattern:

• Internal SLO: 99.5%
• External SLA: 99.0%
• Buffer: 0.5% for measurement differences and incident response time

Measurement point matters too. Your SLA should specify where you measure — load balancer, application, or synthetic probe. Clients may measure from their office in Kathmandu while you measure from Singapore. Discrepancies cause disputes unless the contract is explicit.

Define excluded maintenance windows carefully. Planned deploys on a Deployer 7 pipeline still cause brief blips. Either exclude announced maintenance or accept that deploys consume error budget. Sister sites I maintain on shared EC2 use scheduled low-traffic windows for this reason.

Remedies should match business impact. Service credits of 10% of monthly fees are common for missed uptime tiers. Avoid punitive clauses your team cannot operationalise. Legal teams care about clarity; engineers care about measurability. Both must agree on the same SLI definition.

Support and maintenance contracts often bundle SLA tiers. Bronze might guarantee 99.0%; Gold might guarantee 99.5% with faster response times. Price the tier against real infrastructure cost, not optimism.

How do error budgets connect SLIs and SLOs?

An error budget is the allowed unreliability within your SLO window. If your SLO is 99.5% over 30 days, your error budget is 0.5% — roughly 3.6 hours of failure in a 720-hour month.

Error budgets turn reliability into a shared resource. Product wants features. Engineering wants stability. The budget gives both teams a negotiation frame.

When budget remains, ship aggressively. Run experiments. Deploy on Friday if your pipeline is solid. When budget burns fast, freeze risky releases. Focus on hardening, caching, and query optimisation. This is the core SRE loop described in alerting with Prometheus Alertmanager.

Example error budget tracker

For a 99.5% monthly SLO on 1 million requests:

• Allowed bad requests: 5,000
• Bad requests so far this month: 1,200
• Remaining budget: 3,800 failures (~76% left)
• Burn rate: normal — continue scheduled deploys

Track this on a simple dashboard visible to product and engineering. Hiding the number guarantees surprise escalations.

On a production Laravel application, common budget drains include failed queue jobs, slow MySQL queries under load, and third-party API timeouts. Payment gateway callbacks from eSewa or Khalti that retry incorrectly can burn budget fast. Treat integrations as part of your SLI scope when users depend on them.

How do you implement SLI and SLO monitoring on a Laravel stack?

You do not need Kubernetes to start. A single Ubuntu server running PHP 8.3, Apache, and MySQL can support basic SLO tracking with open-source tools.

Step 1: Instrument the request path

Add middleware to record request duration and status. Push metrics to Prometheus via statsd_exporter or use Laravel's logging with structured JSON. Keep cardinality low — route names, not full URLs with IDs.

/* app/Http/Middleware/RecordSliMetrics.php */
public function handle(Request $request, Closure $next)
{
    $start = microtime(true);
    $response = $next($request);
    $duration = microtime(true) - $start;

    SliMetrics::observe(
        route: $request->route()?->getName() ?? 'unknown',
        status: $response->getStatusCode(),
        duration: $duration
    );

    return $response;
}

Step 2: Track async work

Failed jobs are silent SLI killers. Monitor failed_jobs table growth and job processing latency. Booking confirmations and email delivery often happen in queues. If the queue stalls, users think the site is broken even when HTTP returns 200.

Step 3: Add synthetic checks

Run a cron probe every minute against critical endpoints: homepage, login, checkout health check. Blackbox Exporter works well here. Synthetic uptime complements real-user SLIs.

Step 4: Document and review monthly

Publish an internal SLO document listing each SLI, query, target, and owner. Review burn rates in a 30-minute monthly ops meeting. Adjust targets based on data, not politics.

For infrastructure-heavy setups, pair this with Linux system administration practices: log rotation, PHP-FPM tuning, and opcache reload after deploy. Testing and optimization catches regressions before they eat budget. Enterprise applications benefit from formal SLO reviews tied to release calendars.

Modern teams also explore AIOps for infrastructure monitoring, but walk before you run. Baseline SLIs manually first. AI on bad data amplifies noise.

Rate limiting protects SLIs too. Sudden traffic spikes should not collapse shared hosting. See the guide on API rate limiting and abuse prevention for patterns that preserve availability SLIs under attack.

For multi-region or failover setups, active-active vs active-passive architectures affect how you define availability. Measure per region or globally, but pick one and document it.

Key Takeaways

• SLIs measure user-observable behaviour; pick journeys first, then metrics.
• SLOs are internal targets with error budgets; set them from historical data, not ambition.
• SLAs are customer contracts — always looser than SLOs with explicit measurement points.
• Use burn-rate alerting on short windows so you respond before monthly budgets die.
• Track queue jobs and third-party integrations — HTTP 200 alone is not reliability.
• Review SLI/SLO dashboards monthly with product and engineering at the same table.

People Also Ask

Can you have an SLA without an SLO?

Yes, but it is risky. Many hosting providers promise 99.9% uptime in marketing copy without internal SLO tracking. When incidents happen, they cannot prove compliance or diagnose root cause. Best practice: define SLIs and SLOs first, then set SLAs below those internal targets.

How many SLIs should a small web app have?

Start with three to five SLIs covering your critical user journeys: availability, latency for key routes, and one business outcome metric. A law-firm portal might track document upload success. An eCommerce site tracks checkout completion. More SLIs mean more operational overhead.

What is a good SLO for a brochure WordPress site?

99.0% to 99.5% monthly availability is reasonable for a marketing site on managed hosting. Latency SLOs matter less unless lead forms drive revenue. Upgrade targets when the site handles bookings, payments, or client portals.

Who owns SLOs — developers or operations?

Both, plus product. Engineering instruments and responds. Product prioritises reliability work against features. Leadership approves SLA commitments that finance and legal sign. Reliability is a team sport, not a silo.

Make reliability measurable on your next project

SLI, SLO, and SLA explained is only useful once the numbers live in a dashboard your team trusts. Start with one critical user journey, one SLI, and one SLO. Add alerting that respects sleep schedules. Keep SLAs honest and below internal targets.

If you want help defining SLOs for a Laravel app, API, or booking platform, review the portfolio of production systems or read more on the blog. For hands-on reliability work — monitoring setup, performance tuning, and maintenance — explore speed optimization and hosting services, or contact us to discuss your stack.