Skip to main content

SLOs View

Define and track Service Level Objectives for your Meteor application.

Overview​

SLOs let you set concrete reliability targets for your application and track whether you're meeting them. Instead of just reacting to alerts, SLOs give you a budget-based approach to reliability -- you decide how much downtime or degradation is acceptable, and SkySignal tracks how much of that budget you've used.

Navigate to SLOs in the sidebar to get started.

SLO Types​

SkySignal supports four types of SLOs:

TypeWhat It MeasuresExample Target
AvailabilityPercentage of successful requests99.9% of requests return non-error responses
LatencyPercentage of requests within a time threshold95% of requests complete under 500ms
Error RatePercentage of requests without errorsError rate stays below 1%
ThroughputRequest volume stays within expected rangeAt least 100 requests/minute during business hours

Key Metrics​

Each SLO tracks three core numbers:

Target Percentage​

The reliability goal you've set. For example, 99.9% availability means you're allowing 0.1% of requests to fail within the measurement period.

Error Budget Remaining​

Your error budget is the amount of unreliability you can tolerate. If your target is 99.9%, your error budget is 0.1% of total requests for the period.

The error budget visualization shows how much budget you've consumed and how much remains. When you're burning through budget quickly, it's a signal to slow down on deployments and focus on stability.

Burn Rate​

How fast you're consuming your error budget relative to the measurement period. A burn rate of 1x means you'll exactly exhaust your budget by the end of the period. Higher than 1x means you're on track to blow through it early.

Burn rate is the most useful metric for day-to-day decisions. A sudden spike in burn rate usually means something just broke and needs attention.

Health Status​

SLOs have four health states:

  • Healthy - Within budget, burn rate is sustainable
  • Warning - Budget consumption is elevated, keep an eye on it
  • Breaching - Burn rate is high, budget is being consumed too fast
  • Breached - Error budget exhausted for the current period

Creating an SLO​

  1. Navigate to SLOs in the sidebar
  2. Click Create SLO
  3. Configure:
    • Name - Descriptive name (e.g., "API Availability" or "Checkout Latency")
    • Type - Availability, latency, error_rate, or throughput
    • Target - Your target percentage (e.g., 99.9%)
    • Period - Measurement window (e.g., 30 days rolling)

Example SLO Configurations​

# API Availability
Name: API Availability
Type: availability
Target: 99.9%
Period: 30 days

# Method Latency
Name: Method Latency P95
Type: latency
Target: 95% of requests under 500ms
Period: 7 days

# Error Rate
Name: Low Error Rate
Type: error_rate
Target: 99% error-free
Period: 30 days

Burn Rate Alerts​

SkySignal can alert you when your error budget is being consumed too fast. This is more useful than simple threshold alerts because it accounts for the rate of change, not just the current value.

For example, a brief spike that burns 0.1% of your budget is different from a sustained issue burning 5% per hour. Burn rate alerts catch the sustained problems that will actually exhaust your budget.

Best Practices​

Start with a Few Key SLOs​

Don't try to cover everything at once. Start with 2-3 SLOs that represent what your users actually care about:

  • Can they load the app? (availability)
  • Is it fast enough? (latency)
  • Are they hitting errors? (error rate)

Set Realistic Targets​

A 99.99% target sounds great but gives you almost no error budget to work with. For most Meteor apps, 99.5%-99.9% is a practical starting point. You can always tighten it later.

Use Error Budgets to Make Decisions​

When your error budget is healthy, deploy freely. When it's running low, slow down and focus on reliability. This turns "should we deploy today?" from a gut feeling into a data-driven decision.

Next Steps​