An automation job calls a retrieve-data API for switch inventory. One failure shows a connect-timeout with errno in the client log; another shows HTTP 400 with a body complaining about a bad template field. How should these be classified for next action?

Classify the connect-timeout with errno as a transport or reachability failure and the HTTP 400 with a bad-template-field body as an application-level rejection of the payload. A timeout and low-level errno mean the client never completed a healthy HTTP exchange—routing, firewall, DNS, TLS handshake, or an overloaded path may be involved—so the next wrench is network and connectivity troubleshooting. An HTTP 400 with an explanatory body means the transport succeeded and the API understood enough of the request to refuse it; the next wrench is fixing the template field, schema, or request construction. Log fields that separate errno or timeout from status-plus-body decide which playbook to open for switch-inventory automation.

Treating both as identical application bugs so you only change the JSON schema misreads the timeout: there was no successful application response to validate against a schema. Treating both as transient platform outages so you only open a vendor TAC case misreads the 400: the platform answered with a clear client-error body pointing at your template. Treating both as DNS failures because neither returned HTTP 200 is wrong for the 400 (DNS and HTTP already worked) and incomplete for the timeout (DNS is only one of several possible causes).

Exam caveat: some gateways map upstream problems into misleading status codes—still prefer the most specific signal you have (errno versus typed 400 body) and verify with a known-good request. Operational check: from the same automation host, test TCP/TLS reachability to the retrieve-data endpoint for the timeout case, and for the 400 case replay a minimal inventory request that omits the disputed field to confirm the body complaint disappears.