An expired token rarely looks like a failure

When a model call fails, it usually throws a clear error. When an integration's credential expires or is revoked, the failure mode is often quieter. A write-back call returns a 401 that a catch block silently retries into a dead end. A read call against a narrowed scope returns an empty result instead of an error, and the workflow concludes there is simply nothing to process.

OAuth 2.0, the protocol behind most API integrations, is explicit that access tokens expire and must be refreshed or reissued. RFC 6749 defines the `expires_in` lifetime and the refresh token flow precisely because tokens are not meant to work forever. A workflow that doesn't plan for that expiration isn't violating the protocol, it's just assuming a condition the protocol never guarantees.

Permission drift happens without a deploy

A credential can stop working for reasons that have nothing to do with the workflow's own code. An admin rotates an API key during a security review. A connected app's OAuth scope gets narrowed when someone tightens access in the source system. A service account tied to an employee's identity gets deactivated when that employee leaves.

None of those changes touch the workflow's codebase, so none of them show up in a deploy log or a code review. The only place the effect is visible is in the behavior of the integration itself, which is exactly why auth failures are undercounted as a cause of workflow incidents.

  • Rotated API keys from routine security hygiene
  • Narrowed OAuth scopes when access policies tighten
  • Deactivated service accounts tied to a person who left
  • Expired refresh tokens after a long period of inactivity

Treat every connected credential as a tracked dependency

List every credential the workflow depends on: the system it connects to, who owns the account it runs as, when it expires or rotates, and what breaks downstream if it stops working. This list is small for most workflows, but it is almost never written down anywhere.

Auth0's guidance on token practices recommends giving every token an explicit expiration and a deliberate revocation strategy, rather than letting tokens remain valid indefinitely by default. The same discipline applies to service accounts and API keys: an explicit owner and a known expiry turn a surprise outage into a scheduled rotation.

Give auth failures their own signal

A 401 or 403 is a different problem from a timeout or a malformed response, and it deserves a different alert, not a line in a generic error log. Route authentication and authorization failures to a path that names the specific credential and the system it belongs to, so the person who can rotate it finds out before a customer or a reviewer does.

The workflows that recover fastest from this failure mode are the ones where an auth error is loud and specific. The ones that lose the most time are the ones where it was absorbed quietly as 'no new items to process' for days before anyone looked closely enough to notice.