Q092: Frontend SLOs and Error Budgets

What Interviewers Want To Evaluate

This question tests whether you can reason about frontend reliability using measurable service quality targets. Interviewers want SLI, SLO, error budget, user impact, monitoring, alerting, ownership, and how reliability trade-offs influence release decisions.

Senior frontend engineers should understand that reliability is not only backend uptime. A frontend can be available while users still cannot complete tasks.

Short Interview Answer

Frontend SLOs define target reliability for user-facing experiences, such as successful page load, checkout completion, low JavaScript error rate, acceptable INP, or successful form submission. SLIs are the measurements, SLOs are the targets, and error budgets describe how much unreliability is acceptable. I would choose SLOs for critical flows, monitor them by route and segment, alert on meaningful burn, and use budget health to guide release risk and remediation priorities.

Detailed Interview Answer

Traditional uptime is not enough for frontend quality. A server can return 200 while the page throws a JavaScript error, fails hydration, blocks input, or hides a required button.

Start by choosing user journeys:

What workflows are critical?
What does success mean to the user?
How can the browser measure success?
What segments matter?
What is an acceptable failure rate?
Who owns response?
What actions happen when budget burns?

SLI Examples

Frontend service level indicators can include page load success rate, JavaScript error-free sessions, checkout completion success, form submission success, search interaction success, LCP p75, INP p75, hydration error rate, and API request success from the browser.

The best SLIs map to user experience, not only technical counters.

SLO Examples

An SLO might be “99.5% of checkout sessions can submit payment without client-side failure over 28 days” or “p75 INP for dashboard filter interaction remains under 200ms for enterprise tenants.”

SLOs should be realistic and based on product criticality.

Error Budgets

An error budget is the amount of failure allowed while still meeting the SLO. If the budget is burning quickly, the team may slow risky releases and prioritize reliability work.

Error budgets help balance feature velocity and reliability with data instead of emotion.

Alerting

Alerts should be actionable. Alerting every small spike creates fatigue. Alert when a critical user journey is impacted or an error budget burns fast enough to require action.

Segment alerts by route, browser, tenant type, release, and region when useful.

Ownership

Every SLO needs an owner. A platform team may provide observability tooling, but route or product owners must respond to flow-specific failures.

If nobody owns an SLO, it is only a dashboard decoration.

Common Mistakes

A common mistake is using only backend uptime as a proxy for frontend reliability. Another is setting SLOs so strict that the team is always failing and stops trusting them.

Another mistake is alerting on technical noise without user impact.

Senior Trade-Offs

Strict SLOs protect critical workflows but may slow experimentation. Loose SLOs avoid alerts but may hide poor user experience.

The senior answer should connect reliability targets to product importance and release decisions.

Code or Design Example

A frontend SLO definition can be kept as configuration.

type FrontendSlo = {
  name: string;
  journey: string;
  sli: "error-free-session" | "interaction-success" | "web-vital" | "submission-success";
  target: number;
  windowDays: number;
  owner: string;
  alertWhenBudgetBurnsFast: boolean;
};

The details depend on the observability stack, but the shape keeps ownership and target clear.

Production Example

Suppose a dashboard has 99.9% server uptime, but 4% of sessions hit a JavaScript chart error after a new release. From a user perspective, the dashboard is unreliable.

A frontend SLO for error-free dashboard sessions would catch this earlier than backend uptime.

Release Decisions

If error budget is healthy, the team may accept normal release risk. If budget is nearly exhausted, the team may pause risky changes, increase canary coverage, or prioritize stability fixes.

This turns reliability into a planning input.

Lead Engineer Perspective

A lead engineer should define which flows deserve SLOs, ensure instrumentation is trustworthy, assign owners, and use SLOs in planning conversations.

SLOs should create clarity, not blame.

Revision Notes

Frontend SLOs measure user-facing reliability. SLIs measure, SLOs target, and error budgets guide risk.

Key Takeaways

A frontend can be technically deployed and still fail users. SLOs help teams see and manage that reality.

Follow-Up Questions

1. What is the difference between SLI and SLO?
2. What frontend journeys need SLOs?
3. How do error budgets guide releases?
4. Why is backend uptime insufficient?
5. What makes an alert actionable?
6. How do you segment frontend reliability data?
7. Who owns SLO response?
8. How do Web Vitals fit into SLOs?
9. How do you avoid alert fatigue?
10. How do SLOs influence planning?

How I Would Answer This In A Real Interview

I would explain that frontend SLOs should map to critical user journeys. I would define SLIs, targets, error budgets, owners, alerts, and release actions, then give an example such as checkout success, dashboard error-free sessions, or INP for key interactions.