When an Announced Billing Change Gets Paused at the Last Minute: Designing Automation That Doesn't Rush the Cutover

Implementation: a three-state cutover flag

First, define the flag. Picture it living in a config file or KV.

type CutoverPhase = "announced" | "confirmed" | "reverted";
 
interface CutoverFlag {
  id: string;                   // e.g. "billing-credit-metering-2026-06"
  phase: CutoverPhase;
  announcedEffectiveAt: string; // announced date (reference only; not used to decide)
  lastProbedAt?: string;        // last time we confirmed at runtime
  confirmStreak: number;        // consecutive "new regime" observations
  revertStreak: number;         // consecutive "old regime" observations
}
 
// On receiving an announcement, just register it as announced
function registerAnnouncement(id: string, effectiveAt: string): CutoverFlag {
  return {
    id,
    phase: "announced",
    announcedEffectiveAt: effectiveAt,
    confirmStreak: 0,
    revertStreak: 0,
  };
}

announcedEffectiveAt is recorded, but only as reference so a human can understand the situation. The decision (the pickRunMode equivalent) looks at phase alone.

function resolveRunMode(flag: CutoverFlag): "subscription" | "credit-metered" {
  // New path only when confirmed. Otherwise (announced / reverted) the old path
  return flag.phase === "confirmed" ? "credit-metered" : "subscription";
}

That single move let the June 15 pause pass with zero damage. Even after the announced date, phase stayed announced, and the code kept quietly choosing the subscription path.

Confirming at runtime that the change really took effect

The runtime signal that justifies a switch differs by the kind of change. For a billing-category change like this one, reading the category returned by a usage/billing endpoint is the natural choice. For a model retirement, whether a light request to the target model ID returns model_not_found is a reliable signal.

What matters here is to not change state on a single observation. With staged rollouts or transient inconsistencies, the signal can flip back and forth. I add hysteresis: a state transition happens only when I observe the same result twice in a row.

// probe returns a boolean: "is it the new regime now?" (swap per change)
async function advanceCutover(
  flag: CutoverFlag,
  probe: () => Promise<boolean>,
): Promise<CutoverFlag> {
  const isNewRegime = await probe();
  const now = new Date().toISOString();
  const next: CutoverFlag = { ...flag, lastProbedAt: now };
 
  if (isNewRegime) {
    next.confirmStreak = flag.confirmStreak + 1;
    next.revertStreak = 0;
    // After two consecutive new-regime observations, move to confirmed
    if (next.confirmStreak >= 2 && flag.phase !== "confirmed") {
      next.phase = "confirmed";
    }
  } else {
    next.revertStreak = flag.revertStreak + 1;
    next.confirmStreak = 0;
    // After being confirmed, two consecutive old-regime observations -> reverted
    if (next.revertStreak >= 2 && flag.phase === "confirmed") {
      next.phase = "reverted";
    }
  }
  return next;
}

You write the body of probe per change. For the billing example, read from the usage endpoint whether you are being metered against the separate credit pool, and return that. Keep the probe purely about observation, and concentrate the transition logic in advanceCutover — that keeps things testable as the number of change types grows.

Before / After: from a hardcoded date to a deferrable design

Place the opening anti-pattern next to this design.

// Before: trust the announced date, switch immediately, break on retraction/delay
const BILLING_CUTOVER = new Date("2026-06-15T00:00:00+09:00");
function pickRunMode(now = new Date()) {
  return now >= BILLING_CUTOVER ? "credit-metered" : "subscription";
}
 
// After: only record the announcement; switch when a runtime signal confirms twice
const flag = await loadCutoverFlag("billing-credit-metering-2026-06");
const updated = await advanceCutover(flag, probeBillingRegime);
await saveCutoverFlag(updated);
const mode = resolveRunMode(updated); // stays on subscription while announced

The difference is that the thing deciding "when to switch" moved from the calendar to runtime observation. Before trusts the intent of an announcement. After waits for the fact of an effective change. What automation should protect is the fact — the pause made that clear.

Detecting retractions and delays, and rolling back automatically

The reverted state exists to handle a change that goes live and is later pulled back. Staged-rollout withdrawals and emergency rollbacks do happen. After confirmed, two consecutive old-regime observations drop phase to reverted, and resolveRunMode returns the old path again.

The one thing I always include in a rollback is to fire a notification to a human immediately. Reverting to the old path automatically is the safe behavior, but if you can't later trace why it reverted, operations become opaque. The instant the state transitions, I leave a one-line log with the flag ID, the direction of the transition, and the latest probe result, and notify myself. The code works correctly in silence; the human receives only the facts. I think that division of labor is what lets automation keep running for a long time.

function onPhaseChange(prev: CutoverFlag, next: CutoverFlag) {
  if (prev.phase === next.phase) return;
  const line = `[cutover] ${next.id}: ${prev.phase} -> ${next.phase} ` +
    `(confirm=${next.confirmStreak}, revert=${next.revertStreak}, at=${next.lastProbedAt})`;
  notifySelf(line); // one channel — Slack / email / log — is enough
}

How this lands in solo-developer automation

As an indie developer, I run four sites at Dolice on auto-publishing pipelines. Generating each site's articles includes passing quality gates, several of which run headless. That is exactly why an announcement that "the billing category is changing" was a heavy one — it touches the cost structure directly. And yet it was paused on the day. Had I switched on the announced date, every retraction would have meant rolling back four sites' worth of operations by hand.

The decision order I keep in practice has three parts. First, when an announcement arrives, add the implementation, do not enable it. Register it as announced and keep the old path. Second, base the switch on a runtime signal, not a date. If you can't write a probe for a change, I take that as a sign it shouldn't be switched automatically at all. Third, confirm a state transition with two consecutive observations, and notify a human when it transitions.

Whether an announced change gets retracted is not something I can control. What I can control is the code's posture toward the announcement. I want to keep the line clear: meet announcements with preparation, and decide switches by fact. I hope it helps anyone else juggling several pieces of automation as they shape their own design.