Service Level Objectives (SLOs)

Define, track, and alert on reliability targets for your services with SLOs and error budgets.

What Are SLOs?#

A Service Level Objective (SLO) is a target value for a measurable indicator of your service's reliability. SLOs answer the question: "How reliable should this service be?" They give your team a shared, quantifiable goal that balances reliability with the speed of shipping new features.

SLOs sit at the heart of Site Reliability Engineering (SRE) practice:

SLI (Service Level Indicator) -- the metric you measure (e.g., request latency, error rate)
SLO (Service Level Objective) -- the target for that metric (e.g., 99.9% of requests under 500ms)
Error Budget -- the amount of unreliability you can tolerate before violating your SLO

When your error budget is healthy, you can ship aggressively. When it's depleted, you focus on reliability.

Why SLOs Matter#

Without SLOs, reliability decisions are subjective. Teams argue over whether a 0.5% error rate is "fine" or "catastrophic." SLOs remove this ambiguity:

Objective decision-making -- clear thresholds for when to stop shipping and focus on reliability
Error budgets unlock velocity -- teams can take calculated risks knowing exactly how much budget remains
Incident prioritization -- SLO burn rate tells you how urgently to respond
Stakeholder alignment -- product, engineering, and operations share a common reliability language
Cost optimization -- pursuing 100% uptime is infinitely expensive; SLOs help you pick the right target

SLO Indicators#

JustAnalytics supports three built-in SLI types. Each measures a different dimension of reliability.

Latency (p99)#

Measures the 99th percentile response time for a service or endpoint. This ensures that even your slowest requests meet a performance bar.

Indicator: latency_p99
Good event:  request completes in < threshold
Total event: all requests

Example: "99.5% of requests to the checkout service complete in under 800ms."

Error Rate#

Measures the proportion of requests that return a successful (non-5xx) response. This is the most common SLI type.

Indicator: error_rate
Good event:  request returns 2xx or 3xx status
Total event: all requests (excluding 4xx client errors, optionally)

Example: "99.9% of API requests return a successful response."

Availability#

Measures the proportion of time your service is reachable and responding. This is based on uptime check data from your configured health checks.

Indicator: availability
Good event:  health check returns 2xx within timeout
Total event: all health check attempts

Example: "The payments API is available 99.95% of the time."

Creating an SLO#

Navigate to Dashboard > Monitoring > SLOs and click Create SLO.

Step 1: Define the SLI#

Choose the indicator type and configure its parameters:

Name:        Checkout Latency
Indicator:   latency_p99
Service:     checkout-service
Environment: production
Threshold:   800ms

For error rate SLOs, you can optionally exclude specific status codes or endpoints:

Name:        API Error Rate
Indicator:   error_rate
Service:     api-gateway
Environment: production
Exclude:     /health, /ready
Exclude 4xx: true

Step 2: Set the Target#

Choose a target percentage. This is the proportion of "good" events over the time window:

| Target | Allowed Downtime (30d) | Allowed Errors (1M requests) | |--------|----------------------|------------------------------| | 99% | 7h 18m | 10,000 | | 99.5% | 3h 39m | 5,000 | | 99.9% | 43m 50s | 1,000 | | 99.95% | 21m 55s | 500 | | 99.99% | 4m 23s | 100 |

Step 3: Choose the Time Window#

The time window defines the period over which the SLO is evaluated:

7 days -- short-term view, useful for new services or rapid iteration
28 days -- aligns with a four-week sprint cycle (recommended default)
30 days -- calendar month, common for external SLAs
90 days -- quarterly view, smooths out one-off incidents

Rolling windows continuously recalculate. At any moment, the SLO looks at the last N days of data.

Step 4: Save and Configure Alerts#

Optionally attach burn-rate alerts (covered below) so you get notified before the error budget runs out.

Error Budgets#

The error budget is the inverse of your SLO target, applied over your time window. If your SLO is 99.9% over 30 days, your error budget is 0.1% of total requests (or ~43 minutes of downtime).

How Error Budgets Are Calculated#

Error Budget = (1 - SLO Target) x Total Events in Window

Example:
  SLO Target:    99.9%
  Total Requests: 1,000,000 (in 30 days)
  Error Budget:   (1 - 0.999) x 1,000,000 = 1,000 errors allowed

Budget Consumption#

As bad events occur, they consume your error budget. The SLO dashboard shows:

Budget remaining -- percentage of error budget not yet consumed
Budget consumed -- how much has been used
Projected depletion -- at the current burn rate, when will the budget run out

Budget Remaining: 62.3%
Consumed Today:   4.2%
Burn Rate (1h):   1.8x  (consuming budget 1.8x faster than sustainable)
Projected Depletion: 8 days

When the budget hits 0%, your SLO is in violation for the current window.

Using Error Budgets for Decisions#

Error budgets drive operational decisions:

| Budget Remaining | Action | |------------------|--------| | > 50% | Ship freely, take risks | | 25-50% | Ship with caution, monitor closely | | 10-25% | Freeze risky deploys, investigate issues | | < 10% | Reliability-only work until budget recovers | | 0% (violated) | Full reliability freeze, postmortem required |

Burn Rate Alerts#

A burn rate measures how fast your error budget is being consumed relative to the sustainable rate. A burn rate of 1.0 means you'll exactly exhaust your budget at the end of the window. A burn rate of 10.0 means you'll exhaust it 10x faster.

Multi-Window Burn Rate Alerts#

JustAnalytics uses the multi-window, multi-burn-rate approach recommended by Google SRE. This reduces false positives by requiring the burn rate to be elevated over both a long and short window.

Alert: Critical SLO Burn
  Long window:   1 hour at 14.4x burn rate
  Short window:  5 minutes at 14.4x burn rate
  Severity:      critical
  Action:        Page on-call

Alert: Warning SLO Burn
  Long window:   6 hours at 6x burn rate
  Short window:  30 minutes at 6x burn rate
  Severity:      warning
  Action:        Create ticket

The default burn rate thresholds:

| Severity | Burn Rate | Long Window | Short Window | Budget Consumed if Sustained | |----------|-----------|-------------|--------------|------------------------------| | Critical | 14.4x | 1h | 5m | 2% in 1 hour | | High | 6x | 6h | 30m | 5% in 6 hours | | Medium | 3x | 1d | 2h | 10% in 1 day | | Low | 1x | 3d | 6h | 10% in 3 days |

Configuring Burn Rate Alerts#

When creating or editing an SLO, toggle Enable burn rate alerts and customize thresholds:

SLO: API Error Rate (99.9% / 30d)

Alerts:
  ✅ Critical:  14.4x burn rate over 1h  → PagerDuty
  ✅ Warning:   6x burn rate over 6h     → Slack #alerts-warning
  ☐  Low:       1x burn rate over 3d     → (disabled)

Burn rate alerts integrate with your existing notification channels (Slack, PagerDuty, email, webhooks).

SLO Dashboard#

The SLO overview page shows all your SLOs at a glance:

Summary View#

Each SLO card displays:

Name and service -- which service and indicator
Current SLI value -- the actual measured value (e.g., 99.92%)
Target -- the SLO target (e.g., 99.9%)
Status -- healthy (green), at risk (yellow), violated (red)
Budget remaining -- percentage bar showing remaining error budget
Burn rate -- current 1-hour burn rate

Detail View#

Click an SLO to see:

SLI over time -- chart showing the indicator value over the full window
Error budget burn-down -- chart showing budget consumption over time
Bad events timeline -- individual errors, slow requests, or downtime periods
Related alerts -- any burn rate alerts that fired
Related incidents -- incidents linked to this SLO

Filtering and Grouping#

Filter SLOs by:

Status -- healthy, at risk, violated
Service -- specific service name
Environment -- production, staging, etc.
Indicator type -- latency, error rate, availability

Group SLOs by service or team to get a team-level reliability view.

API Reference#

Create and query SLOs programmatically:

// Create an SLO via the API
const response = await fetch('/api/dashboard/slos', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    name: 'API Latency P99',
    indicator: 'latency_p99',
    target: 99.9,
    windowDays: 30,
    service: 'api-server',
    environment: 'production',
    threshold: 500,       // 500ms for latency SLOs
    excludePaths: ['/health'],
  }),
});

// Query SLO status
const slos = await fetch('/api/dashboard/slos?status=at_risk');
const data = await slos.json();

// Response shape:
// {
//   slos: [{
//     id: 'slo_abc123',
//     name: 'API Latency P99',
//     currentValue: 99.87,
//     target: 99.9,
//     status: 'at_risk',
//     budgetRemaining: 23.4,
//     burnRate1h: 2.1,
//     windowDays: 30,
//   }]
// }

Best Practices#

Choosing the Right Target#

Start conservative -- begin with 99% and tighten as your service matures
Match user expectations -- an internal admin tool doesn't need 99.99%
Consider dependencies -- your SLO can't exceed the reliability of your dependencies
Align with SLAs -- if you promise customers 99.9%, your internal SLO should be tighter (e.g., 99.95%)

Common Mistakes#

Setting targets too high -- 99.99% sounds good but leaves almost no room for deploys or experiments
Too many SLOs -- start with 1-3 per service covering the most critical user journeys
Ignoring the error budget -- an SLO without a process for acting on budget depletion is just a dashboard metric
Using SLOs as punishment -- SLO violations should trigger process changes, not blame

Recommended Starting Points#

| Service Type | Indicator | Target | Window | |-------------|-----------|--------|--------| | User-facing API | error_rate | 99.9% | 30d | | User-facing API | latency_p99 | 99.5% (< 500ms) | 30d | | Background worker | error_rate | 99.5% | 30d | | Landing page | availability | 99.95% | 30d | | Internal tooling | error_rate | 99% | 30d |

Iterating on SLOs#

Review your SLOs quarterly:

Was the target too tight (constant violations) or too loose (never at risk)?
Does the SLI still reflect what users care about?
Are burn rate alert thresholds generating actionable notifications?
Should you add SLOs for new services or retire them for decommissioned ones?

SLOs are a living contract between your team and your users. Adjust them as your service and understanding evolve.