Reliability Is a Lifecycle, Not a Retry Button
Axios reliability is not one setting and it is not the same as retrying every rejected Promise. This chapter focuses on how Axios classifies an outcome, controls the lifetime of a request, and limits the resources used by bodies and responses. The practical goal is to distinguish an HTTP decision from a transport failure, an intentional cancellation from a timeout, and a useful diagnostic record from a log that exposes sensitive configuration.
A request can fail after the server responds, before a response exists, while its body is being transformed, or while the caller is deliberately ending the work. Those situations may all appear in one catch block, but they do not call for the same remedy. Reliability starts by preserving the difference.
Start with what the error still contains
Axios errors are designed to carry context. An AxiosError can include a message, an Axios error code, the request configuration, the underlying request object, a response, and the response status. isAxiosError can narrow an unknown value in TypeScript, and toJSON() produces a structured snapshot for diagnostics.
The most useful first split is whether a response exists. If error.response is present, the server returned something and Axios applied its status policy or a later response transformation rejected it. The caller can inspect the status, response headers, and response data. A response with status 404 is not evidence that the network was unavailable; it is evidence that the server answered and that the application must decide what “not found” means.
If there is no response but error.request exists, Axios created a request but did not receive a usable response. A connection problem, browser network policy, timeout, or an abort can produce this shape. Browser errors can be deliberately opaque: an ERR_NETWORK result may reflect a network problem, CORS, or mixed-content policy, and the browser may withhold the underlying reason from JavaScript. The browser console and server-side observations may be needed to distinguish those causes.
If neither response nor request is useful, the failure may have happened while Axios was preparing the operation. Invalid configuration, an unsupported option, a malformed URL, or a request transformation can fail before a transport is meaningfully in progress. An ERR_INVALID_URL for an HTTP(S) value without the required // is a configuration/input failure, not a server response.
The code is a classification aid, not a complete diagnosis. ERR_BAD_REQUEST and ERR_BAD_RESPONSE describe Axios’s interpretation of a request or response problem. ECONNABORTED may indicate a timeout or another abort unless the transitional timeout setting clarifies it. ERR_CANCELED indicates explicit cancellation. The exact underlying cause can still depend on the adapter and runtime.
A useful diagnostic record keeps the classification evidence together: the Axios code, status when present, whether a response or request exists, the operation’s destination category, and the request’s relevant policy. It should not blindly serialize the live error object. The error retains its configuration by reference, and that configuration may contain authorization headers, passwords, client certificates, or other secrets.
Separate status policy from transport failure
validateStatus decides Promise control flow
Axios’s default status validator resolves responses in the 2xx range and rejects responses outside it. That rule is a policy applied after a response arrives. It does not alter the HTTP status, and it does not say that a 4xx response was a network failure.
An application can replace the rule when the API’s semantics call for it. A search endpoint might treat 404 as an ordinary empty result.