SRE Interview Questions (2026): The SLO Math Interviewers Actually Test

An SLI is the actual metric you measure. Request latency, error rate, availability, something you can put a number on right now. An SLO is the internal target you set for that metric, say 99.9% of requests succeed in a rolling 30-day window. An SLA is the external, usually contractual, promise to a customer, and it typically sits below your internal SLO on purpose, so you breach your own target before you ever breach theirs.

Mixing up SLO and SLA in an interview is a small tell, but it's a tell. It usually means you've read about the concept, not lived with the pager.

Because you want room to notice and fix a problem before it becomes a contractual, financially penalized breach. If your SLA promises 99.9% and your internal SLO is also 99.9%, the first time you slip, you're already in breach territory with zero warning. Setting the SLO at 99.95% gives you a real buffer, a signal that says "you're drifting toward a problem" before the problem starts costing money.

Acknowledge it. That single click stops the alert from escalating to a second person and buys you a few minutes to actually think instead of reacting to your phone buzzing again. It sounds too simple to be a real interview answer, but the number of people who open a dashboard first and forget to ack is not small.

Anything currently flaky, anything you silenced or snoozed and why, and anything that's "probably fine but keep an eye on it." A handoff that's just "nothing to report" from someone who was actually paged twice that week isn't a real handoff, it's a person hoping the next shift doesn't ask follow-up questions.

Monitoring watches for failure modes you already anticipated, a dashboard, a threshold, an alert you set up in advance because you expected that specific thing to break. Observability is the property of a system that lets you ask a question you didn't think to ask ahead of time and still get an answer, because the data's structured well enough to support it. Monitoring answers known unknowns. Observability is built for the unknown unknowns.

Synthetic monitoring runs scripted checks from outside, on a schedule, whether or not a real user is hitting the site right now, which makes it good for catching an outage during low-traffic hours when real user monitoring would have almost no data to work with. Real user monitoring shows what actual traffic experiences, including edge cases synthetic checks never think to script. Most mature setups run both, since synthetic catches the silent 3am outage and RUM catches the degradation that only shows up under real, messy production traffic.

IaC makes infrastructure changes reviewable, versioned, and reproducible, which turns "what changed in prod last week" from a guessing game into a git log. The reliability wins that follow: drift detection, catching when reality no longer matches what the code says should exist, fast disaster recovery since you can rebuild from source instead of institutional memory, and change management that goes through the same review process as application code.

LastRoundAI's DevOps engineer interview questions page goes deeper on Terraform state, locking, and a real state-corruption recovery scenario if your loop pushes further into the tooling side of this than an SRE round usually does.

Availability is a point-in-time measurement, is the system up and answering requests right now, expressed as a percentage of uptime over some window. Reliability is a much longer-term property, whether the system does what it's supposed to do correctly and consistently over its whole lifetime, including under load, through dependency failures, and across version changes.

A service can be available 99.99% of the time and still be unreliable if it silently corrupts data, returns wrong answers, or degrades under load without erroring. A service can also have a rough availability number for one bad week during a deploy and still be considered reliable overall, because the team caught it fast and the underlying design held up. In practice availability is one input into reliability, not a synonym for it, and SLOs usually try to capture both by pairing an availability SLI with a correctness or latency SLI.

A runbook is a written, step-by-step procedure for handling a specific known failure mode or operational task, restart this service, fail over this database, roll back this deploy, without requiring the person following it to already understand the system deeply. Good ones include the exact commands to run, what output to expect, and what to check next depending on that output.

The value is speed and consistency at 3am when the on-call engineer is half asleep and has never touched this particular service before. Writing runbooks before an incident forces someone who knows the system to think through the failure mode calmly, instead of trying to reconstruct the right sequence of commands live while a page is going off. Teams that only write their first runbook as a postmortem action item are still gaining something, but they're choosing to learn the hard way first.

MTTD is mean time to detect, how long between something actually breaking and someone or something noticing it broke. MTTR is mean time to resolve, how long between detection and the issue being fixed for users. MTBF is mean time between failures, how often things break in the first place. They measure different parts of the same story.

A team can have a low MTTR and still cause real user impact if MTTD is high, because nobody noticed the outage for 40 minutes before anyone even started fixing it. A team can also obsess over MTTR while ignoring MTBF, getting very good at cleaning up messes that keep recurring instead of fixing the root causes that create them. Tracking all three tells you whether to invest in better alerting, faster incident response, or actual reliability engineering, and they usually point to different fixes.

A canary deployment ships a new version to a small slice of traffic or a small subset of instances first, watches the relevant metrics for that slice, and only proceeds to the rest of the fleet if those metrics look healthy. If the new version has a bug, the damage is contained to whatever percentage of users hit the canary, and rolling back means pulling a handful of instances out of rotation instead of undoing a full fleet-wide release.

The part that actually makes it work is picking metrics that would catch the failure mode you're worried about, error rate and latency on the canary compared to the baseline, not just whether the canary process started. A canary that only checks process health will happily pass while quietly returning wrong data or 500s that don't show up as crashes. It also needs enough traffic on the canary to be statistically meaningful, one request a minute tells you almost nothing for an hour.

A rollback reverts to the last known good version, undoing the bad change entirely. A roll-forward ships a new fix on top of the current broken version instead of going backward. Rollback is almost always faster and safer when it's available, because you're returning to a state that was already proven in production, and most deploy systems are built to make that path quick.

Roll-forward becomes the only real option when going backward isn't safe, most commonly because the bad deploy included a database migration or schema change that the old code can't work against anymore, or because the incident is data corruption that reverting code alone won't undo. The practical lesson is that migrations should stay backward compatible with the previous code version for at least one deploy cycle, specifically so rollback stays an option when something goes wrong.

A liveness probe answers whether a process is still functioning, or whether it should be killed and restarted. A readiness probe answers a narrower question, whether this instance can serve traffic correctly right now. Kubernetes uses liveness failures to restart a container and uses readiness failures to pull an instance out of the load balancer's rotation without killing it.

The mistake that actually causes outages is making the liveness check too strict, tying it to a downstream dependency like a database connection. If the database has a blip, every pod's liveness check fails at once, Kubernetes restarts all of them simultaneously, and a brief downstream hiccup turns into a full self-inflicted outage. That database dependency belongs in the readiness check instead, so instances quietly stop receiving traffic during the blip and rejoin automatically once the dependency recovers, without anything getting killed.

An operation is idempotent if running it once has the same effect as running it multiple times with the same input. A GET request is naturally idempotent, it just reads state. A request that charges a card is not idempotent on its own, calling it twice charges the customer twice.

The problem shows up the moment you add retries for reliability, because a client that times out waiting for a response has no way to know whether the request actually succeeded on the server before the timeout. It retries, and if the original request did succeed, the side effect just doubled. The standard fix is an idempotency key, the client generates a unique ID per logical operation and sends it with the request, and the server checks whether it already processed that ID before doing the work again, returning the original result instead of repeating the side effect. Anywhere you're retrying a request with a side effect, payments, sending an email, creating a resource, idempotency keys are what make retries safe instead of just hopeful.

CAP stands for consistency, availability, and partition tolerance. Consistency means every read gets the most recent write or an error. Availability means every request gets a response, even if it's not the latest data. Partition tolerance means the system keeps working even when network communication between nodes breaks down.

The theorem says that when an actual network partition happens, you're forced to choose between consistency and availability. If two sides of a partition can't talk to each other, either one side stops answering requests until it can confirm it has the latest data, choosing consistency over availability, or both sides keep answering with whatever local data they have, which might now disagree, choosing availability over consistency. Partition tolerance itself isn't really optional in real distributed systems, since networks do fail, so in practice CAP is less a three-way menu and more a question of what a system does during a partition. Most real systems pick different answers for different operations rather than one blanket answer for the whole system.

Start from what a user would notice, not from what's easy to instrument. Request success rate and latency at a percentile that matters (p95 or p99, not average, since average hides exactly the slow requests users complain about) cover most services. Availability alone is a weak SLI on its own, a service that's technically "up" but returning 500s for 8% of requests isn't up in any way a user would recognize.

I'd rather see a candidate propose two mediocre SLIs and explain the tradeoff than one perfect-sounding SLI they clearly memorized from a slide.

Start with user pain, not a round number that sounds impressive. What failure rate actually makes people churn, complain, or open a support ticket? The Google SRE book is blunt about this: "100% is probably never the right reliability target," since chasing 99.999% instead of 99.9% can cost 100 times more engineering effort for a difference users on a spotty mobile connection won't even notice.

Historical performance is a decent starting point for what's achievable, but it's not the same question as what's actually needed. A service that's run at 99.99% for a year by accident doesn't need an SLO frozen at that number if nobody would notice a dip to 99.9%.

An error budget is just the SLO's complement. At 99.9% monthly availability, you get about 43 minutes and 48 seconds of allowed downtime a month, and that budget is there to be spent, on risky deploys, experiments, planned maintenance, not hoarded like it's a badge of honor.

Once it's gone, the convention is that feature velocity slows and reliability work gets priority: freeze risky deploys, fix whatever burned the budget, and don't ship the next flashy feature until the number recovers. The honest answer to "what happens when it's exhausted" is a policy decision a team makes, not a law of physics, and I've seen teams say this and then quietly ignore it the first time a launch date is on the line.

Availability isn't the right SLI here. A pipeline that processes 20,000 records an hour but starts 25 minutes late isn't "down," it's late, and treating lateness as downtime just trains everyone to ignore the alert. Better SLIs for batch work: job completion rate, throughput against expected volume, data freshness (how stale is the newest row a downstream consumer would read), and end-to-end latency from trigger to completion.

You don't push back with a vibe, you push back with the cost. Going from 99.9% to 99.99% usually means an order of magnitude more engineering investment, multi-region failover, more redundancy, more on-call load, for roughly 39 fewer minutes of downtime a month. The real question to ask the PM is what specifically breaks for users at 99.9% that wouldn't break at 99.99%, and whether that gap is worth the team that could otherwise be shipping features.

Sometimes the answer is yes, it's genuinely worth it (payments, health, anything with real financial or safety consequences). Often it isn't, and the honest move is saying so instead of quietly agreeing to a number nobody's going to hold the team to anyway.

You probably don't set one. Different consumers have different tolerance and different failure modes, a partner's automated system might retry aggressively and tolerate brief errors fine, while a mobile user staring at a spinner for 3 seconds churns. Splitting the SLI by consumer type, or at minimum tracking them separately even under one nominal SLO, surfaces problems that a blended average would quietly hide.

A hard monthly reset means a team that burned 90% of the budget in the first five days effectively gets a green light to ship risky changes for the remaining 25, since the counter doesn't care how it got spent, only what's left. Rolling windows (a trailing 28 or 30 days, recalculated daily) avoid this cliff-edge behavior, since a bad week ages out gradually instead of resetting all at once on the first of the month.

I think most teams pick calendar-month resets because it's easier to report on, not because it's the better policy. It's the more common answer in interviews too, and it's worth naming the tradeoff even if you'd pick calendar anyway for the simplicity.

"Is the index up" is a binary infrastructure check, not a user-facing signal. A slow search (index technically up, queries taking 4 seconds) or a search returning zero results because of a bad query parser fails the user just as hard as an outage would, and neither shows up if your only SLI is index health. Better SLIs: query success rate, query latency at p95, and a relevance-adjacent signal like zero-result rate, which catches degraded quality a pure uptime check can't see at all.

Because the business doesn't care why something broke while it's still broken, it cares that it's fixed. Rolling back a bad deploy gets the error rate down in minutes; chasing root cause first while users keep hitting 500s optimizes for engineering curiosity over user impact.

You'd break the rule when mitigation itself carries real risk, a rollback that could corrupt data mid-migration, for instance. Those cases are rarer than people think, and "we couldn't roll back safely" is a much stronger answer than "we wanted to understand it first."

Blameless means the postmortem investigates the system conditions that let an error happen, not the person who happened to trigger it. If someone fat-fingered a config change and took down prod, the real finding usually isn't "be more careful," it's "why did our system let one config change with no review or staging step reach production directly."

The consequence, if there is one, falls on the process gap, not the individual. That's a genuinely different thing from consequence-free, and interviewers who ask this question are usually checking whether you conflate the two.

Real timestamps, exact commands run, and exact metric values at each point, not "engineers investigated and found the issue." A timeline someone could replay from the raw entries is useful six months later when a similar-shaped incident happens. A vague narrative isn't.

It's a mechanism, not a root cause. It doesn't explain why the memory limit was wrong in the first place. "The memory limit was copied from a different service with roughly a quarter of the traffic, and nobody revisited it after launch" is a real root cause, because it points at an actual, fixable process gap instead of restating the symptom in slightly more technical language.

A cascading failure starts small: one component fails, load shifts onto the components next to it, and they fail too. The classic version is a caching layer going down, every request suddenly hits the database directly, the database saturates, upstream services start timing out, and users retry, which pushes even more load onto a system that's already drowning.

Circuit breakers stop this by failing fast once a downstream dependency is clearly unhealthy, instead of letting every caller queue up and wait for a timeout that never comes. Load shedding, deliberately rejecting some percentage of requests, usually the least important ones first, protects the system's core function even if it means some users see an explicit error instead of a slow, silent failure.

They should almost never be the same person on anything past a trivial incident. The IC's job is coordination, tracking the timeline, deciding when to escalate, communicating to stakeholders, not writing the fix. Someone debugging with one eye on Slack updates works slower and misses things. Splitting the roles is one of the cheapest reliability wins a team can make, and a lot of smaller teams skip it purely because they don't have the headcount to spare.

The list itself isn't the problem, the lack of ownership is. "We should add more monitoring" with nobody's name and no date attached is the item that's still open a year later, because it belongs to everyone and therefore to no one. Every action item needs a named owner and a real date, and honestly, 14 items usually means the team is trying to fix everything at once instead of picking the two or three changes that would have actually prevented this specific incident.

USE (Utilization, Saturation, Errors) is built for infrastructure resources, CPUs, disks, network interfaces, anything you'd describe as busy or full. RED (Rate, Errors, Duration) is built for request-driven services, how many requests, how many failed, how long did they take. Reach for USE first when you're debugging something that smells like a hardware or OS-level bottleneck. Reach for RED first for a web service or API, since that's the shape of what users actually experience.

Raw error rate has no sense of urgency baked in. A 4% error rate on a service that's normally at 0.1% sounds alarming at 3am, but if that service handles almost no traffic overnight, it might barely dent the monthly error budget. Burn-rate alerting answers a more useful question directly: at this rate, how long until the budget's actually gone. That turns "something's technically elevated" into "we have 40 minutes before this becomes a real problem," which is a much better thing to know at 3am.

Traces, and only traces, really answer that question well. Metrics tell you something's slow in aggregate but not where. Logs tell you what happened on one request in one service but don't connect across service boundaries without deliberate correlation IDs. A distributed trace follows a single request through every hop and shows exactly which span ate the time, which is why tracing adoption tends to track with how many services a company runs, not with company size alone.

You alert on absence and on completion state instead of a rate. Did the job run at all in its expected window, did it finish, and did it process something close to the expected record count. A dead-man's-switch pattern, an alert that fires if a heartbeat you expect doesn't show up, catches the failure mode unique to infrequent jobs, silent non-execution, that request-based alerting doesn't naturally cover.

A symptom-based alert fires on user-visible impact, error rate, latency, availability against an SLO. A cause-based alert fires on an internal condition that might or might not matter, CPU at 80%, a queue depth crossing some number. Symptom-based alerts should page. Cause-based signals are useful context once you're already investigating, but paging on them alone tends to train people to ignore pages, since plenty of 80% CPU spikes never actually hurt a user.

Track memory usage as a trend over days, not just a threshold at a point in time. A leak looks completely normal on any single snapshot and only reveals itself as a slow, steady climb across a graph spanning a week or more. Pairing that trend line with a restart-frequency metric, containers restarting more often as they hit memory limits, well before anyone notices a user-facing symptom, usually surfaces it days before it becomes an incident instead of during one.

Establish a real baseline, then find the cliff edge specifically, at what utilization does latency start degrading or errors start climbing, not just what the average load looks like on a normal Tuesday. Provision headroom above that cliff, not above the average, since the average tells you almost nothing about the spike that actually matters.

Autoscaling helps, but it isn't instant. Spinning up a new instance typically takes 2 to 5 minutes depending on the platform and image size, and a traffic spike during that window is still entirely your problem. Pre-warmed capacity or predictive scaling matters more than people expect for genuinely spiky workloads, since reactive autoscaling is always a little behind the actual spike.

Toil is manual, repetitive, automatable work that doesn't produce any lasting improvement, restarting the same flaky service by hand every week instead of fixing why it's flaky, for example. The SRE model's usual target is toil under 50% of an engineer's time, leaving the rest for actual engineering work that reduces future toil.

I'll be honest, I don't know many teams that measure this rigorously enough to give you a real number when asked. Most teams have a rough sense that toil is "too high" without ever quantifying it, and admitting that in an interview is a more credible answer than pretending your team tracks it to the percentage point.

Reliable automation is idempotent, running it twice gives the same result as running it once, so a retry after a partial failure doesn't make things worse. It's observable, it logs what it did and emits a metric, so a silent failure doesn't just vanish into a cron log nobody reads. And it has a manual override that actually works under pressure.

That override matters more than people give it credit for. Automation with no kill switch fails fast and at scale exactly when you need to stop it the most, and "we automated it but there's no way to pause it" is a genuinely scary answer to give an interviewer, or to discover during a real incident.

Filter events to the rolling window, count successes against total events, and compare against the SLO target as a ratio, not a raw count, since the window size shifts as time moves forward. The edge case interviewers actually check for: what happens with zero events in the window. Returning 100% by default is a common but debatable choice, some teams prefer returning "insufficient data" instead of a number that looks falsely reassuring.

from datetime import datetime, timedelta

def is_within_slo(events, window_hours=24, slo_target=0.999):
  """events: list of (timestamp: datetime, success: bool)"""
  cutoff = datetime.utcnow() - timedelta(hours=window_hours)
  recent = [e for e in events if e[0] >= cutoff]
  if not recent:
    return None # insufficient data, don't fake a number
  successes = sum(1 for _, ok in recent if ok)
  ratio = successes / len(recent)
  return ratio >= slo_target, ratio

Plain exponential backoff, doubling the wait each retry, is fine until every client that failed at the same moment also retries at exactly the same moment, which recreates the same thundering-herd problem you were trying to avoid. Jitter, adding a random component to each wait, spreads retries out so they don't all land on the server in the same instant.

import random
import time

def retry_with_backoff(fn, max_attempts=5, base_delay=0.5, max_delay=20):
  for attempt in range(max_attempts):
    try:
      return fn()
    except Exception:
      if attempt == max_attempts - 1:
        raise
      delay = min(max_delay, base_delay * (2 ** attempt))
      jittered = random.uniform(0, delay)
      time.sleep(jittered)

A token bucket refills at a fixed rate up to a max capacity, and every request costs one token. Requests get allowed as long as tokens are available, which naturally permits short bursts up to the bucket's capacity while still enforcing a steady average rate over time, unlike a fixed window counter that can let through double the intended rate right at a window boundary.

import time

class TokenBucket:
  def __init__(self, capacity, refill_rate_per_sec):
    self.capacity = capacity
    self.tokens = capacity
    self.refill_rate = refill_rate_per_sec
    self.last_check = time.monotonic()

  def allow(self):
    now = time.monotonic()
    elapsed = now - self.last_check
    self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)
    self.last_check = now
    if self.tokens >= 1:
      self.tokens -= 1
      return True
    return False

Treat their downtime as a certainty you're planning for, not a risk you're hoping against. Set a client-side timeout shorter than their documented SLA implies you'd need, add a circuit breaker so a slow dependency doesn't tie up your own thread pool waiting on it, and decide in advance what degraded behavior looks like when it's down, queue the payment for retry, or fail the checkout with a clear message, rather than deciding that live during an incident.

The follow-up worth having ready: what happens to a request that was in flight when the dependency died mid-call. If your answer is "we're not sure," that's an honest gap worth naming rather than papering over.

Uptime as a single monthly percentage hides the shape of the downtime completely. One service could have had twelve, 4-minute blips spread evenly through the month, mildly annoying, easy to ignore. The other could have had one 4-hour outage during peak business hours on a Monday morning. Same total minutes, wildly different user experience.

This is why a lot of mature SRE orgs track burn rate and incident count separately from the raw uptime percentage. A single number is a summary, and summaries lose the information that actually explains why support tickets spiked.

A single burn-rate alert has an ugly tradeoff: a short window catches fast burns quickly but false-alarms on brief blips, a long window is stable but takes hours to catch a real fast burn. Multi-window alerting runs both at once, a short window (say 5 minutes) combined with a longer window (say 1 hour) that both have to agree before paging, which cuts false positives without losing the fast-burn catch.

The follow-up interviewers ask is what burn rate actually triggers each: a rate that would exhaust a 30-day budget in about 2 hours pages immediately, and a slower burn that would take 3 days can wait for a ticket instead of a 3am wake-up.

Acknowledge the page immediately so it doesn't escalate and wake up the next person on the rotation for no reason. Check what changed first, correlate the failure against the deploy and config-change timeline before anything else, since most incidents trace back to a recent change rather than sudden hardware failure. If something shipped in the last hour, roll it back and ask questions later. If nothing shipped recently, check upstream dependencies (the push provider, a queue, a database) before assuming the bug lives in your own service.

Post a status update in the incident channel inside the first few minutes even with no root cause yet. "Still investigating, notifications fully down since 2:04am, checking recent deploys" beats silence every time, and silence during an incident reads as either panic or incompetence to whoever's watching.

There's no universal number, but the signal is visible once you look: pages per week per person climbing, on-call engineers burning vacation days right after their rotation ends, or a rotation where the same two people always get swapped in because everyone else is uncomfortable being primary. A rotation of two is a red flag almost everywhere; a rotation of six or eight with a healthy secondary tier is usually fine, but the honest answer is you have to look at the page volume and the human toll, not just count headcount on a roster.

I don't have a clean number that applies across companies here. What I do know is that teams who never measure page frequency per person tend to discover the problem only after someone quits.

Forty panels is a research tool, not an incident tool. During an actual page, nobody has the working memory to scan 40 graphs and synthesize an answer under pressure, so people default to whatever three or four signals they already trust from memory, and the other 36 panels exist purely for the quarterly review deck.

I'd rather see a team with one tight, ugly dashboard that shows the RED metrics for the top five services than a beautiful 40-panel one nobody opens at 3am. Dashboard sprawl is a cultural failure mode more than a technical one, and it's one of the more honest "what would you change" answers a candidate can give.

Cardinality explosion happens when a metric label has effectively unlimited possible values, a user ID or a raw request path as a label, for instance, instead of a bounded set like a status code or a region. Every unique label combination becomes its own time series, so a metric with a user-ID label on a service with a million users can generate a million time series from one metric definition, and most observability vendors bill on time series count.

The fix is usually bucketing or dropping the offending label, aggregate by endpoint pattern instead of raw path, drop user ID from the metric and keep it in logs instead, where high cardinality is expected and priced differently. This one's more of an operational cost lesson than a pure technical concept, and it's the kind of thing you usually only learn after a surprise bill.

Storing every raw value doesn't scale on a high-traffic service, so the standard move is an approximation structure like a t-digest or a histogram with fixed, exponentially-sized buckets, trading a small amount of accuracy for bounded memory. A t-digest keeps more resolution at the tails, where p95 and p99 actually live, and less in the dense middle of the distribution, which is exactly the tradeoff you want since nobody's paging you about the p50 at 3am.

For an interview, a simplified fixed-bucket histogram is usually an acceptable answer even if you can't implement a full t-digest from memory, as long as you can explain why bucket boundaries need to be denser near the tail than near the median.

class LatencyHistogram:
  def __init__(self, bucket_bounds):
    self.bounds = bucket_bounds # e.g. [10,25,50,100,200,500,1000,2000,5000]
    self.counts = [0] * (len(bucket_bounds) + 1)
    self.total = 0

  def record(self, value_ms):
    self.total += 1
    for i, b in enumerate(self.bounds):
      if value_ms <= b:
        self.counts[i] += 1
        return
    self.counts[-1] += 1

  def percentile(self, p):
    target = p * self.total
    running = 0
    for i, c in enumerate(self.counts):
      running += c
      if running >= target:
        return self.bounds[i] if i < len(self.bounds) else self.bounds[-1]
    return self.bounds[-1]

When the redundancy adds coordination complexity that becomes its own failure mode. Multi-region active-active setups need consensus or conflict resolution for shared state, and that coordination layer can fail in ways a single-region system never had to worry about at all. More replicas behind a load balancer with a shared config bug means the bug now exists in every replica simultaneously, so redundancy protected you against a hardware failure while doing nothing against a bad deploy, since a bad deploy hits everything at once regardless of replica count.

I think teams reach for multi-region before they've actually earned it more often than not. It solves a specific failure mode, a regional outage, at the cost of new ones, split-brain, cross-region latency, doubled operational surface, and plenty of services would get more real reliability from fixing their deploy process than from a second region they can barely operate correctly in the first one.

A slow burn is the case single-window alerting misses on purpose, since it's designed to ignore anything that wouldn't page urgently. The fix is a second, longer-window burn-rate check running alongside the fast one, something that would exhaust the 30-day budget in about 3 days rather than 2 hours, tied to a ticket or a daily digest instead of a page.

The part interviewers actually want to hear is the tradeoff reasoning, not just "add a second alert." A slow burn that never gets escalated because nobody reads the ticket queue is functionally the same failure as having no alert at all, so the process around the alert matters as much as the alert's existence.