Skip to main content

Rolling Back a Release

Something deployed, something regressed, you need to get back to the last known-good state.

There is no one-click "Rollback to this version" button in Anima. What you do instead is create a new release from a previous good source (a prior release or config), then deploy that new release. The CDN swaps in under a minute; this is functionally a rollback.

When to roll back​

  • Revenue or fill rate dropped immediately after a deploy
  • Browser console shows Wrapper bootstrap failed: or similar errors on pages you didn't change
  • CWV regressed materially on pages where the wrapper runs
  • A bidder stopped receiving bids after a config change
  • You shipped to the wrong domain

If the regression is small and you already know the fix, shipping a corrective release forward is usually faster. Roll back when:

  • You don't yet know the root cause
  • You need to stop the bleeding now and investigate later
  • The regression is large enough that a few minutes in the bad state is expensive

How to roll back​

The pattern is the same regardless of what triggered the issue: find a previous known-good source, copy it into a new release, deploy that release.

Step 1: Find the last known-good release​

  1. Go to Wrapper → Releases.
  2. Look at the status column. Releases are tagged Deployed (currently live), Staged, or Draft. (A release whose deploy attempt failed stays Staged — there's no separate "Failed" status.)
  3. Scan the list for the deployed release that was live before the bad one. The release list also shows the source config or source experiment each release was built from.
  4. Open that release (click the version number) to confirm it's the state you want to return to.
Keep release notes meaningful

Release notes are your best shortcut when scanning history. "Pre-floor-rebalance baseline" is infinitely easier to rollback to than "update".

Step 2: Create a new release from the good source​

Use the Copy action on the previous good release (the row's actions column includes a copy button — same action the row exposes for creating a new release from an existing one).

The copy becomes a new Draft release, pre-populated with the good release's config. Save it. Optionally edit release notes to mark it as a rollback (e.g. "Rollback from v42 — investigating floor regression").

Step 3: Deploy the new release​

From Wrapper → Releases, click the Deploy button (rocket icon) on the draft you just created. Confirm the dialog. The deploy flow is the same as any other release.

Config-only changes propagate through the CDN in roughly 5 seconds. If the bad release involved a library rebuild (code or Prebid modules changed), propagation takes a few minutes while the rollback's library bundle builds.

Step 4: Verify​

Once deployed:

  1. Load a page on your site with ?pbjs_debug=true appended.
  2. In DevTools Console, confirm window.wrapperTag.appVersion has reverted to the previous version.
  3. Confirm AAM Processing <N> ad slots on page appears as expected with no bootstrap errors.
  4. Watch Dashboard → Monetization for the next 15–30 minutes to confirm metrics recover.

See Wrapper Debugging for the full set of browser-side signals.

Preventing the next rollback​

  • Verify in debug mode after every deploy. Load ?pbjs_debug=true on a representative page before you walk away.
  • Use experiments for risky changes. Wrapper → Experiments rolls a change out to a traffic slice instead of 100%, limiting the blast radius. See Experiments.
  • Name releases clearly. A future you rolling back at 2 a.m. will thank present you for the descriptive release note.
  • Deploy during low-traffic windows for major changes. Smaller financial impact if you do need to roll back.

What a roll-back does not restore​

Rolling back reverts wrapper config (slots, layouts, bidders, wrapper settings). It does not revert:

  • Changes you made directly in GAM
  • Changes made in your publisher-side code (the inline tag itself, page templates, ad containers)
  • Data already emitted to reporting

If the bad state corrupted any of those, fixing those is a separate manual step.

When deploy the copy isn't enough​

If the previous release's config was itself stale (e.g. an ad slot that has since been archived), the copy may not deploy cleanly. In that case:

  1. Look at whether the current Draft config (in Wrapper → Configs) is salvageable
  2. Edit it to match the previous good state, or
  3. Copy from an older source config rather than a specific release