# Prove Your SLA: Monitoring for SRE Teams

> Watch Stefan Judis and Braxton Johnston with Shikhar Jagadeesh of Yext on turning an SLA into monitoring you can prove: what the nines really cost, monitoring as code with SLO tiers, functionality checks that sit above individual services, and check results driving automated region failover.

Source: https://www.checklyhq.com/webinars/sre-monitoring/

---

[← All Webinars](https://www.checklyhq.com/webinars/) On-Demand

# Prove Your SLA: Monitoring for SRE Teams

One sample SLA turned into checks, alerting, and monitoring as code. With Yext on how they run it in production.

Date

Oct

1

2026

Time

6 PM CEST

12 PM EST

9 AM PST

You promised 99.9%. Dashboards show infrastructure health, not whether the flows your SLA covers are working for users. In this recorded session, Stefan Judis starts with what the nines actually cost you, 1 minute 26 seconds of downtime a day at 99.9% and nine seconds at four nines, and shows why your check frequency decides whether you find out in time. He then builds the monitoring for a sample SLA in code, with SLO tiers that set frequency, retries, and escalation in one shared file.

Then Shikhar Jagadeesh, Senior Software Engineer at Yext, joins Braxton Johnston to walk through how Yext runs this in production. Checks ride the service definition into production, a service tier decides how often each check runs, and functionality checks sit above the individual services to confirm a customer can actually complete a workflow. He also explains how check results drive automated region failover.

## What we'll cover

- What the nines actually cost: 99% leaves 14 minutes of downtime a day, 99.9% leaves 1 minute 26 seconds, four nines leaves nine seconds, and why check frequency decides whether you catch it in time
- Monitoring as code, live: checks that live in the codebase, tested before they reach production, with SLO tiers that set frequency, retries, and escalation in one shared file
- How checks ride the service definition into production at Yext, so creating a service includes deciding what to monitor, and the teams that build a service own its reliability
- Service health versus functionality health, including the login incident where every service was up and nobody could log in
- Automated region failover driven by check results, plus how Yext handles tiering, check frequency, and cost without everything becoming tier 1

## What you'll walk away with

- — Why your check frequency, not your dashboard, decides whether you can hit your SLA
- — How to tell service health apart from functionality health, and why the second is the one customers feel
- — What to show when someone asks you to prove reliability: the target, the indicator, the check behind it, and the history

## Speakers

Stefan Judis

Developer Relations · Checkly

Shikhar Jagadeesh

Senior Software Engineer · Yext

Braxton Johnston

Senior Solutions Engineer · Checkly