September 10, 2026
11 min read
By Kokil Thapa | Last reviewed: September 2026
Your checkout worked in staging, but production missed revenue for twenty minutes last Tuesday. That gap is exactly why Site Reliability Engineering: SLOs, SLIs and Error Budgets matter. They replace vague "we need 99.9% uptime" promises with numbers you can measure, alert on, and tie to release decisions. On production Laravel stacks I maintain, support and maintenance workflows get calmer once SLIs exist before anyone pages the on-call engineer at midnight.
Quick answer: Site Reliability Engineering: SLOs, SLIs and Error Budgets define what "good" means (SLI), set a target (SLO), and calculate allowed failure (error budget). When budget burns fast, slow releases; when budget is healthy, ship features confidently.
What is Site Reliability Engineering and how do SLIs, SLOs, and error budgets fit together?
Site Reliability Engineering (SRE) treats reliability as an engineering problem with budgets, not a heroic ops culture. Google formalised the model in the Site Reliability Engineering book. The three building blocks stack cleanly.
An SLI (Service Level Indicator) is a measured signal of user-perceived quality. An SLO (Service Level Objective) is your internal target for that SLI over a window, usually 28 or 30 days. The error budget is everything below 100% of the SLO — the failure you are allowed before you must stop shipping and fix reliability.
This is not the same as an SLA. An SLA is a contractual promise to a customer, often with penalties. An SLO should be stricter than your SLA so you have buffer before legal exposure. I have seen teams publish 99.5% SLAs while targeting 99.9% SLOs internally — that 0.4% gap is operational breathing room.
Core vocabulary in one pass
- SLI: The metric — availability, latency, correctness, freshness.
- SLO: The target — "99.95% of requests succeed in 30 days."
- Error budget: 100% minus SLO — at 99.9% over 30 days, you get roughly 43 minutes of error budget.
- Error budget policy: Written rules for what happens at 25%, 10%, and 0% budget remaining.
How do you choose SLIs that reflect real user experience?
Bad SLIs measure what is easy, not what hurts users. CPU under 80% tells you almost nothing about whether a customer completed a payment. Good SLIs sit on the user journey.
For a e-commerce application, I typically define three SLIs:
- Availability: Ratio of successful HTTP responses (non-5xx) to total valid requests.
- Latency: Percentage of requests faster than a threshold — often p95 under 800 ms for HTML, 400 ms for API JSON.
- Correctness: Business-outcome success — payment callbacks confirmed, booking records created, webhook deliveries acknowledged.
On booking platforms like Adventure Third Pole Trek, correctness SLIs matter more than raw uptime. A 200 OK that fails to persist a trek reservation is worse than a brief maintenance page.
Availability SLI with Prometheus-style recording
If you export metrics from Nginx, PHP-FPM, or Laravel middleware, a standard availability SLI looks like this:
# Good events / valid events over 5-minute windows
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total{status!~"(4..)"}[5m]))Exclude client errors (4xx) from the denominator unless they indicate server misconfiguration. A user typing a wrong URL should not burn your error budget. The Prometheus histogram documentation covers latency SLIs with http_request_duration_seconds_bucket series.
Application-level SLIs in Laravel
HTTP status codes lie. Middleware can return 200 with an empty cart. For critical flows, emit structured events:
// After successful payment capture
Metrics::increment('checkout_success_total');
Metrics::increment('checkout_attempt_total');
// On handled failure
Metrics::increment('checkout_failure_total', ['reason' => 'gateway_timeout']);Your SLI becomes checkout_success_total / checkout_attempt_total. That aligns with revenue, which is what the business actually cares about. Pair this with Laravel exception handling patterns so failures are classified consistently.
How do you set SLO targets and calculate error budgets?
Pick a measurement window first. Thirty days is the most common choice. It is long enough to smooth daily noise and short enough to feel urgent. Then choose a target based on user expectations and cost — not round numbers copied from a blog post.
| SLO Target | 30-Day Error Budget | Typical Use Case | Operational Feel |
|---|---|---|---|
| 99.0% | ~7.2 hours | Internal admin tools, batch dashboards | Weekly maintenance OK |
| 99.5% | ~3.6 hours | B2B portals, document uploads | Planned deploy windows |
| 99.9% | ~43.2 minutes | Customer checkout, payment APIs | Strict change control |
| 99.95% | ~21.6 minutes | High-volume payment gateways | Near-zero unplanned downtime |
| 99.99% | ~4.3 minutes | Core auth, multi-region critical paths | Expensive to operate |
Each "nine" is roughly ten times harder than the last. Going from 99.9% to 99.99% is not a 0.09% tweak. It is a different architecture — redundant queues, multi-AZ databases, and rehearsed failover. For most Nepal SMB sites on a single VPS, 99.5% to 99.9% is honest and achievable with solid Linux administration and monitoring.
Error budget math you can reuse
Total minutes in 30 days ≈ 43,200. Error budget minutes = 43,200 × (1 − SLO).
SLO = 99.9% → budget = 43,200 × 0.001 = 43.2 minutes
SLO = 99.95% → budget = 43,200 × 0.0005 = 21.6 minutes
SLO = 99.5% → budget = 43,200 × 0.005 = 216 minutes (3.6 hours)Track remaining budget percentage, not just minutes. Teams reason better about "we have 40% budget left" than "we have 17.3 minutes left." Use a JSON formatter when debugging exported SLO snapshot payloads from your dashboard API during incident reviews.
How does error budget policy change release and incident decisions?
The error budget is a shared contract between product and engineering. When budget is healthy, product owns the roadmap. When budget burns, reliability work takes priority. Without a written policy, every incident becomes a political argument.
A policy I have used on production Laravel deployments:
- Budget above 50%: Normal releases, including weekly feature deploys.
- Budget 25–50%: Reduce deploy frequency; mandatory canary on payment paths.
- Budget 10–25%: Feature freeze except P0 fixes; daily error budget review.
- Budget below 10%: Full release freeze; focus on reliability and postmortems.
This aligns with SLO-driven alerting that avoids 3 a.m. pages. You alert on budget burn rate, not every blip. A two-minute 502 spike during low traffic barely moves a 30-day window. The same spike during checkout hour may consume a week of budget in an hour.
Burn rate: the number that actually pages you
Burn rate tells you how fast you are consuming the full period's budget relative to steady state. A burn rate of 1 means you will exhaust the budget exactly at period end. A burn rate of 14.4 means a 99.9% monthly budget gone in ~2 days if nothing changes.
# Simplified burn rate concept
burn_rate = (error_rate_now / error_rate_allowed)
# Example: 99.9% SLO allows 0.1% errors
# Current error rate = 1.44% → burn_rate = 14.4 (critical)Google's multi-window, multi-burn-rate alerting approach uses short and long windows together. A 2% error spike for five minutes might trip a fast burn alert. Sustained 0.5% errors over six hours trips a slow burn alert. Read the Google SRE Workbook alerting chapter for the full table of window pairs.
How do you implement SLOs on a Laravel or PHP production stack?
You do not need a dedicated SRE team on day one. You need three artefacts: metric instrumentation, a rolling calculation, and a visible dashboard. Start with one service boundary — usually the public web app or the payment API.
Step 1: Instrument at the edge
Nginx log_format with request time and upstream status gives baseline SLIs without code changes. For PHP-FPM pools under load, pair logs with PHP-FPM tuning guidance so slow pools do not hide latency SLI drift.
log_format sli '$status $request_time $upstream_response_time '
'$request_method $uri';Step 2: Export application events
Use OpenTelemetry or a Prometheus client library from Laravel. PHP 8.3+ on Laravel 12 or 13 is a sensible baseline in 2026. Track named spans for checkout, webhooks, and queue jobs. Failed queue retries should increment error counters — silent job death is an SLI blind spot I have debugged on API integration projects.
Step 3: Define recording rules and alerts
Store SLO config as code. A minimal YAML fragment:
slos:
- name: web-availability
target: 0.999
window_days: 30
sli_query: |
sum(rate(http_requests_total{status!~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))Wire burn-rate alerts to Slack first, not PagerDuty. Tune thresholds for a month before paging humans. This matches the approach in our webhook reliability patterns — prove the signal before escalating it.
Step 4: Connect deploy workflow to budget
In GitLab CI or Deployer pipelines I run for sister legal-tech sites, add a pre-deploy gate:
if [ "$SLO_BUDGET_REMAINING" -lt 25 ]; then
echo "Error budget below 25%. Deploy blocked."
exit 1
fiThe script reads a metric endpoint or cache key updated by your monitoring stack. Manual overrides stay logged with ticket IDs. Accountability matters more than automation purity.
What common SRE mistakes should you avoid on small and mid-size teams?
Teams often copy Google's four-nines targets onto a single-server WooCommerce shop. That target is fiction. It creates alert fatigue and erodes trust. Start with honest baselines from thirty days of logs, then tighten quarterly.
Other mistakes I see on real deployments:
- Too many SLIs: More than five per service dilutes focus. Pick availability plus one latency and one business SLI.
- Alerting on SLI noise: Page on burn rate, not raw 500 counts. See caching strategy work — cache stampedes look like outages but need different fixes.
- No error budget policy document: Without written rules, product and engineering negotiate from scratch after every outage.
- Ignoring dependencies: Your SLO is only as good as payment gateways, SMS providers, and DNS. Track vendor incidents separately but acknowledge them in postmortems.
- Skipping postmortems when budget hits zero: A blameless postmortem with tracked actions prevents repeat burns. Pair with chaos testing to validate fixes.
For high-traffic Nepali e-commerce, also watch Dashain and Tihar traffic spikes. Seasonal load is not an incident — unless your SLO assumes peak capacity and it fails. Plan capacity tests through testing and optimization services before festival weeks.
Backups matter too. An availability SLI stays green while data is corrupt. Combine SLOs with restore drills documented in off-site backup automation. Availability without recoverability is a vanity metric.
Key Takeaways
- Define SLIs on user journeys — successful checkout, booking confirmation, API correctness — not server CPU alone.
- Set SLOs one notch stricter than customer SLAs so you have buffer before contractual breach.
- Calculate error budget in minutes per 30-day window and track remaining percentage, not absolute uptime.
- Alert on burn rate with multi-window rules; avoid paging on every short spike.
- Write an error budget policy that freezes releases below 25% remaining budget.
- Start with one service, one dashboard, and thirty days of baseline data before tightening targets.
People Also Ask
What is the difference between an SLI and an SLO?
An SLI is the measured value — such as 99.92% successful requests this week. An SLO is the target you aim for — such as 99.9% over 30 days. The SLI is the score; the SLO is the pass mark.
How much downtime does 99.9% SLO allow?
Over a 30-day window, 99.9% allows roughly 43.2 minutes of error budget. That includes failed requests, not just total server downtime. Partial failures count.
Who owns the error budget — developers or operations?
Both. Product decides how to spend budget on feature velocity. Engineering protects budget through reliability work. SRE practices make that trade-off explicit instead of hidden in outage arguments.
Can you implement SLOs without Kubernetes or Google-scale tooling?
Yes. Nginx logs, Prometheus or Grafana Cloud, and a spreadsheet work for a first version. Laravel apps on Ubuntu with PHP 8.3+ can export metrics from middleware. Start simple; refine after one full measurement window.
Turn reliability targets into daily engineering decisions
Site Reliability Engineering: SLOs, SLIs and Error Budgets give your team a shared language for shipping safely. You stop debating whether last night's deploy was "bad enough" and start reading the budget chart. I have used this on legal-tech portals, booking systems, and e-commerce stacks where a silent checkout failure costs real NPR. The tooling varies; the model does not.
If you want help defining SLIs for a Laravel app, wiring burn-rate alerts, or connecting your Deployer pipeline to an error budget gate, review our e-commerce portfolio work or explore speed and reliability optimization. For a structured reliability audit on an existing production site, contact us with your current stack and traffic profile.
Frequently Asked Questions
Site Reliability Engineering treats reliability as an engineering problem with budgets, not a heroic ops culture. An SLI is a measured signal of user-perceived quality such as availability or latency. An SLO is your internal target for that SLI over a window, usually 28 or 30 days. The error budget is everything below 100% of the SLO — the failure you are allowed before you must stop shipping and fix reliability. Together they form a closed loop from measurement to release policy.
An SLI is the measured value, such as 99.92% successful requests this week. An SLO is the target you aim for, such as 99.9% over 30 days. The SLI is the score; the SLO is the pass mark.
Roughly 43.2 minutes of error budget. That includes failed requests, not just total server downtime — partial failures count.
The error budget is everything below 100% of your SLO — the amount of failure you are allowed before reliability work must take priority over feature releases. Over a 30-day window with roughly 43,200 total minutes, error budget minutes equal 43,200 multiplied by one minus the SLO target. Track remaining budget as a percentage rather than absolute minutes; teams reason better about having 40% budget left than 17.3 minutes left.
An SLA is a contractual promise to a customer, often with penalties for breach. An SLO is an internal reliability target your engineering team manages. Your SLO should be stricter than your SLA so you have buffer before legal or contractual exposure. A pattern seen on real deployments is publishing a 99.5% SLA while targeting 99.9% SLOs internally — that 0.4% gap is operational breathing room before customers are affected.
Bad SLIs measure what is easy, not what hurts users — CPU under 80% tells you almost nothing about whether a customer completed a payment. Good SLIs sit on the user journey. For e-commerce, define availability as the ratio of successful HTTP responses to valid requests, latency as the percentage of requests faster than a threshold such as p95 under 800 ms for HTML or 400 ms for API JSON, and correctness as business-outcome success like payment callbacks confirmed or booking records created. On booking platforms, a 200 OK that fails to persist a reservation is worse than a brief maintenance page.
Total minutes in 30 days is approximately 43,200. Error budget minutes equals 43,200 multiplied by one minus the SLO target. At 99.9% the budget is 43.2 minutes; at 99.95% it is 21.6 minutes; at 99.5% it is 216 minutes or 3.6 hours; at 99.0% it is roughly 7.2 hours. Each additional nine is roughly ten times harder to achieve than the last — going from 99.9% to 99.99% is a different architecture, not a small tweak.
For most Nepal SMB sites on a single VPS, 99.5% to 99.9% is honest and achievable with solid Linux administration and monitoring. Copying Google's four-nines targets onto a single-server WooCommerce shop creates fiction that erodes alert trust. Start with honest baselines from thirty days of logs, then tighten quarterly. A 99.5% SLO gives roughly 3.6 hours of error budget per month — suitable for B2B portals and document uploads with planned deploy windows.
The error budget is a shared contract between product and engineering. Without a written policy, every incident becomes a political argument. A practical policy: above 50% budget remaining, normal releases including weekly feature deploys; at 25–50%, reduce deploy frequency and require canary deploys on payment paths; at 10–25%, feature freeze except P0 fixes with daily error budget review; below 10%, full release freeze focused on reliability and postmortems. When budget is healthy, product owns the roadmap. When budget burns, reliability work takes priority.
Burn rate tells you how fast you are consuming the full period's budget relative to steady state. A burn rate of 1 means you will exhaust the budget exactly at period end. A burn rate of 14.4 on a 99.9% monthly SLO means the budget could be gone in roughly two days if nothing changes. Alert on budget burn rate, not every short spike — a two-minute 502 during low traffic barely moves a 30-day window, but the same spike during checkout hour may consume a week of budget in an hour. Wire burn-rate alerts to Slack first and tune thresholds for a month before paging humans.
You need three artefacts: metric instrumentation, a rolling calculation, and a visible dashboard. Start with one service boundary such as the public web app or payment API. Instrument at the edge with Nginx log_format including request time and upstream status. Export application events via OpenTelemetry or a Prometheus client from Laravel on PHP 8.3+ with Laravel 12 or 13, tracking named spans for checkout, webhooks, and queue jobs. Define SLO config as code with recording rules and burn-rate alerts. Connect your GitLab CI or Deployer pipeline to a pre-deploy gate that blocks deploys when error budget remaining drops below 25%.
Generally no — exclude client errors from the denominator unless they indicate server misconfiguration. A user typing a wrong URL should not burn your error budget. A standard availability SLI divides good events (non-5xx responses) by valid events (excluding 4xx unless misconfiguration). HTTP status codes alone can lie anyway; middleware may return 200 with an empty cart. For critical flows like checkout, emit structured application events and calculate SLI as checkout_success_total divided by checkout_attempt_total so the metric aligns with revenue.
Both. Product decides how to spend budget on feature velocity. Engineering protects budget through reliability work. SRE practices make that trade-off explicit instead of hidden in outage arguments after every incident.
Yes. Nginx logs, Prometheus or Grafana Cloud, and a spreadsheet work for a first version. Laravel apps on Ubuntu with PHP 8.3+ can export metrics from middleware. Start simple with one service, one dashboard, and thirty days of baseline data before tightening targets.
Copying four-nines targets onto infrastructure that cannot support them creates alert fatigue. Defining more than five SLIs per service dilutes focus — pick availability plus one latency and one business SLI. Paging on raw 500 counts instead of burn rate causes unnecessary midnight alerts. Skipping a written error budget policy forces product and engineering to renegotiate after every outage. Ignoring dependencies like payment gateways, SMS providers, and DNS leaves blind spots. Skipping postmortems when budget hits zero allows repeat burns. For high-traffic Nepali e-commerce, also plan capacity for Dashain and Tihar spikes, and combine availability SLIs with backup restore drills since green uptime while data is corrupt is a vanity metric.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
