Why you'd want a backend to fail on purpose

The code that handles a server error — a friendly message instead of a blank screen, a retry, a fallback to cached data — usually only runs by accident, when something happens to actually go wrong in production. That means it's also the code least likely to have been exercised before it ships. Testing it deliberately requires being able to trigger the failure on demand, rather than waiting for a real outage to find out your error state is a spinner that never stops.

Three ways to fake a 500, and when each one fits

  • Breakpoint — pause a live response and set its status to 500 by hand before forwarding it. Best for a single, specific test: you're interacting with the app live, and you want to fake exactly this one response, once.
  • Rules (Mocking) — build a rule that mocks a fixed response for a specific host and path. Best when you want the failure to be repeatable and targeted at one endpoint, without needing to be watching live traffic to trigger it.
  • Network Chaos — one-tap presets for broad resilience testing, not one endpoint in particular. Best for a general "how does my app hold up when things are unstable" pass.

The Server Errors preset isn't scoped the way a Rule is

It's worth being precise about what the built-in Server Errors preset actually does, because it behaves differently from a Rule you build yourself: it matches every host (there's no host list to scope it to), it always injects HTTP 500 specifically, and it does so on roughly a quarter of intercepted traffic — none of which is adjustable from the preset itself. That makes it a fast way to answer "does my app generally cope with a flaky backend," but a poor fit for "does this one endpoint's error handling work," since you can't target it and can't choose a different status.

Build a custom scenario when you need precision

For a targeted test — one endpoint, a specific status code, repeatable on demand — build a custom Chaos scenario instead of using the preset. A custom scenario supports a host filter and lets you pick the status code yourself, which is the combination the Server Errors preset deliberately doesn't offer. This is the right tool when "somewhere in my app, something fails sometimes" isn't the question — "does the profile screen specifically handle a 500 correctly" is.

What to actually check afterward

Triggering the failure is the easy part; the point is what you check once it happens. Does the app show an actual error state a user could understand, rather than an infinite spinner or a silent blank screen? If it retries, does it eventually give up and show something sensible instead of retrying forever? If it falls back to cached data, is that data labeled as stale, or does it look indistinguishable from a fresh response? None of these are things a passing test suite typically catches, because they require the failure to actually happen — which is the whole reason to fake one instead of waiting for a real outage. See Rules, Breakpoints, and Network Chaos for how to set each of these up.