Shipeasy
Flags & ExperimentsCase studies

Maintenance mode with a killswitch

Wrap a subsystem in a break-glass killswitch that defaults off and flips on in seconds during an incident.

Production readyOn this page · 4 min readUpdated · June 19, 2026Works with · Server SDK · CLI · Dashboard

A payment provider is having an outage. Checkout is throwing, retries are stacking up, and your queue is backing up behind a dependency you don't control. You want one switch that takes the whole checkout subsystem into a graceful "we're down for maintenance" state — and one switch that takes it back, the moment the provider recovers.

That switch is a killswitch, not a feature flag.

Why a killswitch and not a flag? A flag is for ramping a feature toward 100%. A killswitch is the opposite shape: a single, default-off bit that lives as a dedicated control surface, is audited on every flip, and propagates fast. You never ramp it — you flip it.

1. Create the switch, default off

shipeasy ks create checkout-maintenance --default false

Default false means "normal operation." The subsystem reads the switch and only enters maintenance mode when someone deliberately flips it on. Safe to ship — it does nothing until an incident.

2. Wrap the subsystem

A killswitch is read with getKillswitch — a synchronous, in-memory lookup. Gate the entry point to the subsystem, not every call site:

import { configure, Client } from "@shipeasy/sdk/server";

configure({ apiKey: process.env.SHIPEASY_SERVER_KEY! });

export async function POST(req: Request) {
  const flags = new Client({ user_id: userId });
  if (flags.getKillswitch("checkout-maintenance")) {
    return Response.json(
      { error: "Checkout is briefly paused for maintenance. Your cart is saved." },
      { status: 503, headers: { "Retry-After": "120" } },
    );
  }
  return processCheckout(req);
}
Fail into the safe state

Return a clean 503 with a Retry-After header and a saved cart — not a raw exception. Maintenance mode should look intentional to the user and to your monitoring, not like a crash.

3. Flip it during the incident

When the pager fires:

shipeasy ks toggle checkout-maintenance --on

Every SDK serves the maintenance branch within the next poll (30s on Free, 60s on Team). No deploy, no env var, no code change. The flip is recorded in the audit log with who and when — so the incident timeline writes itself.

When the provider recovers:

shipeasy ks toggle checkout-maintenance --off

Rollout & measurement plan

  • Default state: off, shipped dark. The switch exists in every environment before you ever need it — provision it on a calm day, not mid-incident.
  • Who can flip: restrict the killswitch to on-call. The flip is the loudest action in your system; treat it like one.
  • Telemetry: killswitches carry no A/B eval telemetry — the health signal is the audit log of flips. Pair it with an alert on your checkout error-rate metric so the switch and the symptom show up on one timeline.
  • Rehearse: flip it in staging once a quarter so the muscle memory exists before the real outage.
Was this page helpful?
✎ Edit this page

On this page