SLO Discovery

Unfault can discover Service Level Objectives (SLOs) from your cloud provider and link them to the route handlers in your codebase. This gives you visibility into which routes are covered by SLOs and surfaces gaps in observability.

Why This Matters

SLOs define what “healthy” means for your service. But SLOs are typically configured at the service level in your cloud provider’s console, disconnected from the code that actually handles requests.

When an SLO breach happens, you need to trace from the alert back to the code. Unfault bridges this gap by linking SLOs directly to your route handlers.

Discovery

To discover and link SLOs, run:

unfault review --discover-observability

Unfault queries your cloud project for existing SLOs and presents them:

We found SLOs in your GCP project that apply to entire services.
Which service does this codebase deploy to?

  [1] unfault-prod-cloudrun-api-slo
      └─ 100% Availability - 99.9% over 30d
      └─ 99% Error Rate - <1% over 30d
      └─ 99% Latency - 95th < 500ms over 7d
  [s] Skip (don't link SLOs)

> 1

Select the service that matches your codebase. Unfault links the SLOs to your route handlers:

✓ Linked 3 SLO(s) to 375 route handler(s).
  (Saved to config, won't ask again for this workspace)

This mapping is saved to your workspace configuration. Future reviews remember the link.

Review Output with SLOs

Once linked, your review output includes observability coverage:

→ Analyzing backend... 7215ms
  Languages: python
  Frameworks: fastapi
  Dimensions: stability · correctness · performance
  Reviewed: 185 files · parse 81ms · engine 1551ms
  Cache: 100%  Trace: 52924be6

Summary
Looks good overall, with a couple spots that deserve a closer look. Two themes
keep showing up: resilience hardening and other cleanup. Starting point:
scripts/create-plan.py (HTTP call to external service in `run` lacks circuit
breaker protec...); then scripts/trigger-throttle.py (HTTP call to external
service in `run` lacks circuit breaker protec...).

────────────────────────────────────────────────────────────
📊 Observability: 3 SLO(s) linked to 125/125 routes (100% coverage)

   ✓ All your HTTP routes are covered by SLOs.
   This gives you visibility into how users are experiencing your service.

Tip: use --output full to drill into hotspots.

The observability section shows:

How many SLOs are linked
How many routes are covered
Coverage percentage
Whether any routes lack observability

Supported Providers

Currently supported:

Provider	SLO Source
Google Cloud	Cloud Monitoring SLOs

Authentication

SLO discovery requires authentication with your cloud provider. Unfault uses your existing credentials:

Google Cloud: Application Default Credentials (ADC)

gcloud auth application-default login

If credentials aren’t available, Unfault skips discovery and continues with the review.

Configuration

After the initial link, the SLO mapping is stored in your workspace. You can view and modify it:

unfault config show

To re-run discovery (useful if you’ve added new SLOs):

unfault review --discover-observability

To unlink SLOs and start fresh, remove the slo section from your workspace configuration.

What Gets Linked

Unfault links SLOs to:

FastAPI routes (@app.get, @app.post, etc.)
Flask routes (@app.route)
Express routes (app.get, router.post, etc.)
Go HTTP handlers (http.HandleFunc, gorilla/mux, chi)

The link is semantic, not syntactic. Unfault understands your routing structure and maps SLOs to the handlers that serve traffic.

Coverage Gaps

If some routes aren’t covered by SLOs, Unfault tells you:

📊 Observability: 2 SLO(s) linked to 118/125 routes (94% coverage)

   ⚠ 7 routes have no SLO coverage:
     → POST /internal/sync
     → GET /internal/health
     → POST /webhooks/stripe
     ...

   Consider whether these routes need observability.

Not every route needs an SLO. Internal health checks and webhook endpoints might be fine without one. The report helps you make that decision consciously.