{AI4WP}

Site Reliability Engineering in WordPress: Errors Will Happen, Design for Them

Introduction

On an experimental, constantly changing site, 404s are not a risk. They are a certainty. We fix them, but we don’t pretend they will disappear.

Site Reliability Engineering (SRE) gives this acceptance a name and a method. The term comes from Google: Benjamin Treynor Sloss founded the first SRE team around 2003, and the book Site Reliability Engineering (O’Reilly, 2016) describes the idea in the chapter “Embracing Risk”.

The video above shows it on a live case: the 404 page on 4wp.dev. An agent searches a RAG index for a relevant product, shows its best guesses, fails, and handles the failure as a designed state. It even has a usage limit.

Five Theses

1. 100% reliability is unreachable. Chasing it costs more than the errors it prevents. The goal is a controlled, predictable level of errors.

2. Errors get a budget. An SLO sets the target (say, 99.9% of requests succeed). The error budget is the rest: 0.1%. Budget left: ship and experiment. Budget spent: stabilize first.

thesis-error-budget

3. Failure is a designed state. A 404 is like empty, loading or error states: it has a layout, a message and a way back. Not a blank page and not a stack trace.

thesis-designed-state

4. Honest codes beat pretty pages. A “not found” page that returns 200 is a soft 404: a bug for SEO and for monitoring. A 404 stays a 404.

5. Every error is a signal. Logging and alerting turn failures into input: error → log → fix or redirect → fewer errors of that type. That is antifragility.

thesis-signal-limit

How It Fits Together

diagram
  • Design defines how failure looks.
  • Server returns honest codes and survives its own failures (404, 410, 500, 503).
  • Frontend turns backend errors into designed states (graceful degradation).
  • Logging and alerting make every failure an improvement.

Checklist

  1. The 404 page exists in the design system and in the theme.
  2. Correct HTTP codes; no soft 404s.
  3. Server fallback pages for 5xx and maintenance.
  4. Every dynamic block has an error state.
  5. 404 and error logs are collected and reviewed.
  6. Alerts fire before users complain.
  7. The project has an agreed error budget.

Summary

Reliability is not the absence of errors. It is the quality of the response to them. On an experimental project 404s are guaranteed; unhandled 404s are not.

More methodologies for WordPress teams on 4wp.dev.