Why this exists

Automated deploy pipelines have a specific way of failing: quietly. Everything looks green. The workflow runs, the logs show success, and yet the live site is serving something stale. This is what that actually looked like, and how the real cause got found.

This one's not anonymized. It's this site's own deploy pipeline, and it's the kind of failure worth documenting exactly because it's so easy to miss.

The starting point

A cache-purge step had been added to the deploy workflow so that pushing a change would automatically clear the edge cache and the new version would go live right away. The workflow itself was confirmed firing correctly on every push - no errors in the run log, every step marked complete.

Except the cache wasn't clearing. Pages kept serving the previous version well after a push had gone out, and there was nothing in the workflow's own output pointing to why.

What was actually happening

The workflow succeeding and the purge succeeding turned out to be two different things. The automation was correctly sending the purge request - but the request itself was being rejected further downstream, and that rejection wasn't surfacing as a workflow failure.

  • The purge request was failing with a routing error (error code 7003) - meaning the zone identifier being sent didn't match a zone the credential had access to.
  • The zone ID stored as a secret was invalid - close enough to a real value that it wasn't obviously wrong at a glance, but wrong enough to fail every request.
  • While tracing how that secret had been set, a separate API token turned up exposed in a place it shouldn't have been - a credential with broader access than the deploy workflow actually needed.

None of this showed up as a failed workflow run, because the workflow's job was just to send the request. Whether the request was accepted was a separate question nothing was checking.

The decision log

The fixes themselves were small. Getting to them required ruling things out in a specific order, and each step changed what looked like the likely cause.

Decision 1: Confirm the workflow first, not the credentials

The instinct when a purge silently fails is to assume the credentials are wrong. Instead, the first step was confirming the workflow was actually running and reaching the request step at all - it was. That ruled out a triggering problem and pointed the search toward the request itself, not the automation around it.

Decision 2: Read the actual error code, not just "it failed"

A routing error like this one points to a specific mismatch - the credential and the zone ID don't agree on what's being accessed. That's a narrower problem than "the request failed," and it's the difference between guessing at permissions and checking one specific value.

Decision 3: Replace the zone ID, then verify against a live purge

Once the invalid zone ID was identified, the fix itself was a one-line secret update. The more important part was not declaring it fixed until a real purge had been triggered and confirmed against the actual cache state, rather than trusting a clean workflow run on its own.

Decision 4: Treat the exposed token as its own separate issue

Finding the exposed token in the middle of this diagnosis was tempting to treat as a side note. It got handled as its own fix instead - revoked from the account's profile-level token list, not just removed from wherever it had been visible, since a token stays valid until it's revoked at the source regardless of where it was exposed.

Before and after

Before

  • Workflow reporting success on every run
  • Cache purge silently rejected with a routing error
  • Live site intermittently serving stale content
  • No workflow-level signal that anything was wrong
  • An overscoped API token sitting exposed

After

  • Zone ID corrected and verified against a live purge
  • Cache clears confirmed immediately after each push
  • Exposed token revoked at the account level
  • Diagnosis and fix documented for the next time something looks "successful" but isn't

What this actually took

The fix was a secret update and a revoked token - a few minutes of actual work. Getting there took longer, because "the workflow succeeded" had to be separated from "the thing the workflow was supposed to do actually happened." Those aren't the same claim, and treating them as the same claim is exactly how this kind of failure stays invisible.

The bigger takeaway wasn't the specific error code. It was a reminder to verify outcomes, not just completions - a workflow finishing without an error is not the same as confirming the thing it was supposed to change actually changed. Diagnosing deploy and infrastructure failures like this one falls under Security & Trust - the same discipline applied to this site's own pipeline.

Frequently asked questions

How would I know if this is happening on my own site?

The clearest sign is a mismatch between what a deploy or automation log says and what's actually visible on the live site. If a workflow reports success but changes aren't showing up where they should, it's worth checking whether the workflow is confirming an outcome or just confirming it ran.

Is this specific to one platform's setup?

The specific error code is tied to how one CDN provider validates requests, but the underlying pattern - a step reporting success while the request it sent gets silently rejected downstream - shows up across a lot of automated deploy setups, regardless of provider.

What's the actual risk of an exposed token like this?

An exposed credential is valid until it's revoked, regardless of whether anyone has misused it yet. The safest assumption is that visibility alone is the risk, and it should be revoked at the source as soon as it's found rather than just removed from where it was seen.

Not sure what's actually happening behind your own deploys?

A short conversation is usually enough to tell whether there's a quick answer or something deeper worth tracing.