Returning 200 with an error body trains clients to ignore your API. Status codes are part of the contract.
Returning 200 with an error body trains clients to ignore your API.
Use 2xx for success, 4xx for client mistakes, 5xx for server failures — consistently.
Load balancers, monitors, and SDKs all react to status codes. Lying to them creates silent failure modes.
Why this shows up in real IT work
Information technology fails in boring, repeated ways: unclear ownership, untested recovery, and tools used without a question. Use 2xx for success, 4xx for client mistakes, 5xx for server failures — consistently. That sentence is the filter for everything below.
Most teams already own the software that could help. What they lack is a sequence they can run under pressure. Returning 200 with an error body trains clients to ignore your API. The gap between knowing the tool exists and using it deliberately is where outages and slow weeks live.
You do not need a new platform to start. You need a first check small enough to survive a noisy on-call, then a second check that confirms the first one. That is how operational skill compounds without requiring a conference talk every morning.
The mechanism in plain language
Load balancers, monitors, and SDKs all react to status codes. Lying to them creates silent failure modes. When you treat the problem as bad luck, you get folklore. When you treat it as a diagnosable system, you get a checklist.
Notice how often teams wait for a perfect rewrite before they fix the path in front of them. Delivery follows verification more often than the reverse. Use 2xx for success, 4xx for client mistakes, 5xx for server failures — consistently. Prove the symptom, then change one variable.
Also notice the stories people tell mid-incident: that this stack is uniquely cursed, that only one hero can fix it, that documentation is for other people. Those stories are loud and mostly useless. Replace them with a sequence you can run with half a dashboard and a half-honest status page.
A practice you can run this week
- Map validation failures to 400 or 422 with a stable error shape.
- Use 401/403 correctly; do not conflate authn and authz.
- Reserve 404 for missing resources, not “something went wrong.”
- Treat 429 as a first-class signal with Retry-After when you can.
- Alert on 5xx rates, not on “message contains error.”
Run the practice once without optimizing it. Optimization is how people postpone the first restore drill or the first key rotation. After three honest reps, adjust one friction point — the alert threshold, the runbook command, or the access path — and keep going.
A scene from ordinary operations
A mobile client retries forever on logical errors because your API always returned 200. You fix statuses and retries calm down.
That scene is intentionally ordinary. IT skills earn their keep in ticket queues, deploy windows, and quiet Sundays — not only in viral outage postmortems.
If your own version of the scene looks messier, that is fine. Skill is not aesthetic. Skill is whether the next similar moment goes slightly better because you had a plan.
The pitfall that quietly undoes the practice
Wrapping every failure in HTTP 200 because a frontend once expected it.
If you catch yourself doing that, stop and return to the smallest next verification. Do not scrap the whole system because one change window went sideways. Returning 200 with an error body trains clients to ignore your API.
Another quiet undoing: collecting more tooling instead of practicing the tooling you already have. Read this once, then open the terminal or console and run step one. Articles do not change uptime. Reps do.
A short checklist
- Decide what “done enough” looks like before you start.
- Remove one friction from the environment or the runbook.
- Run the smallest verification even on a busy day.
- Review once, without courtroom energy.
- Ask yourself: Would a reverse proxy’s health check interpret this response correctly?
Limits and honesty
No single habit fixes underfunding, hostile vendors, or legacy constraints you did not choose. Practices sit on top of reality; they do not erase it. Use what helps, ignore hustle folklore that blames individuals for structural debt, and escalate when the checklist is not enough.
Still, many of the leaks in a week are local and trainable. Access hygiene, DNS checks, backup restores, and clear alerts respond to practice. That is why this belongs under IT on Swiftener: useful moves for systems work, not vibes for performing expertise.
If someone on your team needs a softer entry, share the scene and the checklist — not a lecture. Invitation beats correction.
The one test
Would a reverse proxy’s health check interpret this response correctly?
If the answer is no, shrink the practice until it becomes yes. Use 2xx for success, 4xx for client mistakes, 5xx for server failures — consistently.
Then teach the move to someone else in one minute. Teaching is how the skill sticks in your own hands.
Come back to this page when the pager gets loud again. The point is not to memorize a brand of best practice. The point is to leave with a move you can use before the shift ends.