Errors & Observability

An error taxonomy that maps causes to responses, boundaries that stop internals leaking, and the logs, metrics and traces that let you answer questions you did not anticipate.

An Error Taxonomy That Maps Cause to Response

Eight kinds of failure, each with a different status, a different caller action and a different owner — instead of one 500 for everything.

Q · When something goes wrong in a handler, how do I decide what the caller should be told and what they should do about it?
Error Boundaries: Three Translations, Not One

A driver error becomes an application error becomes an API response — and each translation adds context while removing internals.

Q · Where should an error be caught, and what should it look like at each layer it passes through?
Not Leaking Your Internals

Stack traces, SQL fragments, internal hostnames and library versions in an error response are free reconnaissance for an attacker.

Q · What is safe to put in an error response, and what am I giving away without noticing?
Correlation Ids That Survive Every Hop

One identifier that follows a request through services, queues and workers — including the hop into a background job, which is where it is usually dropped.

Q · A customer reports a failure at 14:32. How do I find every log line, in every service, that belongs to that one request?
What a Backend Should Actually Log

Six questions every log line should help answer, and the one category of data that must never appear in one.

Q · What do I log, at what level, so that a production question can be answered without redeploying?
Structured Logging

Log events as typed key-value records rather than sentences, because the consumer is a query engine, not a person reading a terminal.

Q · Why does it matter whether a log line is a sentence or a JSON object?
The Metrics a Backend Must Emit

Request rate, error rate, latency, in-flight requests, pool usage, queue depth, cache hit rate and dependency latency — eight numbers that make a service legible.

Q · Which numbers does a backend have to publish for anyone to know whether it is healthy?
Tracing From the Backend's Side

What a service must emit and propagate so one request's path across processes becomes a single readable timeline.

Q · A request takes three seconds and touches five services. Which one spent the time, and what do I have to emit for that question to be answerable?
Health Checks: Startup, Readiness, Liveness

Three different questions with three different consequences — and a liveness check that fails on a dependency outage turns a bad hour into a much worse one.

Q · What should a health endpoint check, and what happens when it says no?