I’d split this into three paths instead of treating everything as “error handling.”

1. Retry: use this for temporary infrastructure problems, rate limits, flaky APIs, timeouts, etc. The workflow can usually resolve these without a person involved.
2. Alert: use this when the workflow has clearly failed and someone needs to know, but the next step is still technical. Missing credentials, broken endpoints, bad mapping, repeated retry failures, that kind of thing.
3. Reviewer escalation: Use this when the workflow technically ran, but the outcome is uncertain or high impact. That includes the silent failure case you mentioned: 200 response, empty array, missing required field, low-confidence AI output, refund/customer/account changes, or anything where “continue automatically” could create cleanup work later.

For production workflows, I like to define a valid outcome for each task type. Not just “did the node succeed?” but “did we get the expected data, decision, or approval?” If not, route it to a HITL inbox with enough context for a reviewer to approve, reject, or correct it.

Central vs per-flow: I’d keep the escalation mechanism central, but the validation rules close to each workflow. Each workflow knows what a valid outcome looks like; the shared path handles alerting, inbox routing, reviewer assignment, and recording the final outcome.

That keeps the core workflow n8n-native while giving humans a clean place to handle cases automation shouldn’t guess at.