Why does logging only err.Error() from http.Client.Do leave a postmortem guessing?

## Stringifying is a one-way door `err.Error()` produces a message for a human to read. Everything that made the error queryable - its concrete type, its methods, its wrapped chain - is gone the moment you take that string. And the client's errors are built precisely so that the type carries the diagnosis: - `errors.As(err, &urlErr)` with `var urlErr *url.Error` yields `Op`, `URL`, and `Timeout()`. - `errors.Is(err, context.DeadlineExceeded)` says a deadline you attached to the request expired. - `errors.Is(err, context.Canceled)` says something cancelled the call deliberately. - `errors.Is(err, io.EOF)` says the connection closed before any response arrived. - `errors.As(err, &dnsErr)` with `var dnsErr *net.DNSError` isolates name resolution, and its `IsNotFound` field separates a missing record from a resolver outage. - `errors.As(err, &opErr)` with `var opErr *net.OpError` isolates dial and connection-level failures. That is six distinct incident classes with six different owners and six different responses. Flattened to a string, they are one line each in a log, distinguishable only by eyeballing English text. ## The failure that is not in the log at all There is a second, larger hole. A job that logs on `err != nil` records nothing when the partner answers `500`, because that exchange succeeded and `err` is nil. In a real incident the pattern is bleak: the partner served error pages for four hours, the job decoded them into an empty result and reconciled against nothing, and the error log for the whole window is empty. So the status code must be recorded on its own path, not folded into error handling. If you only ever ask 'was there an error', you have instrumented the least likely failure and ignored the most likely one. ## The text is not a contract A typical message is `Get "https://api.example.com/v1/orders": dial tcp 10.0.0.7:443: connect: connection refused`. Inside it are a resolved IP address, a port, and a syscall message whose exact wording depends on the operating system. None of that is stable. Two consequences follow: - **Dashboards that group by message substring break silently.** They do not error; they just stop matching, and the graph goes flat while the incidents continue. - **Metric labels built from `err.Error()` have unbounded cardinality**, because every distinct address and port produces a new series. The fix for both is the same: label with the classification, a handful of stable values such as `timeout`, `canceled`, `dns`, `refused`, `eof`, `http_5xx`, and leave the raw text in the log message where a human will read it. ## What to record Classify once, at the call site, while the type is still intact, and emit fields: ```go var urlErr *url.Error isTimeout := errors.As(err, &urlErr) && urlErr.Timeout() slog.Error("partner call failed", "method", req.Method, "url", req.URL.String(), "timeout", isTimeout, "canceled", errors.Is(err, context.Canceled), "deadline", errors.Is(err, context.DeadlineExceeded), "err", err) ``` Note that `url.Error` already carries the method and URL, so you are not inventing context - you are surfacing what the error was holding all along. ## Keep the chain alive above the call site The same mistake has a subtler form: wrapping with `%v` instead of `%w`. `fmt.Errorf("reconcile partner orders: %v", err)` produces a brand-new error whose entire content is text, which is exactly the loss described above, just moved one frame up. `%w` keeps the chain, so a caller three levels away can still run `errors.As` for `*url.Error` or `errors.Is` for `context.DeadlineExceeded` and reach its own conclusion. ## The postmortem test A useful bar to hold your client code to: after an incident, can you answer 'how many of these were deadlines, how many were refused dials, how many were 500s, and did the mix change over the four hours' from what was recorded, without re-reading raw text? If not, the instrumentation is wrong, and adding more log lines will not fix it - classifying earlier will.