How to Write a Killswitch for Critical Bugs

A critical bug ships. Players are losing save files, duplicating items, or crashing the game on every third match. You can’t push a patch for 48 hours because the console storefront cert process is slow. In the meantime, the feature is live and every player who touches it is hurt. A killswitch is the difference between a 20-minute outage and a two-day crisis.

What a Killswitch Is

A killswitch is a server-controlled boolean that the game reads on startup. Every feature that might need to be disabled quickly is gated behind a killswitch. When you discover a critical bug, you set the flag to off on your backend, and every player who launches the game within the next few minutes sees the feature disabled.

Killswitches are not a replacement for patches. They are a faster emergency brake. The next patch fixes the actual bug; the killswitch contains the damage until then.

The Simplest Implementation

You do not need a complicated backend. A single JSON file on a static host works fine.

// Hosted at https://yourgame.io/config.json
{
  "version": 12,
  "flags": {
    "matchmaking_enabled": true,
    "cloud_saves_enabled": true,
    "microtransactions_enabled": true,
    "new_weapon_pack_enabled": true,
    "world_boss_event_enabled": false
  },
  "messages": {
    "world_boss_event_enabled": "Temporarily disabled for maintenance. Back soon!"
  }
}

On game startup, the client fetches this file, caches the result, and reads flags from it.

public class Killswitches
{
    private static Dictionary<string, bool> _flags = new();
    private static Dictionary<string, string> _messages = new();

    public static async Task Load()
    {
        try
        {
            var http = new HttpClient();
            http.Timeout = TimeSpan.FromSeconds(5);
            var json = await http.GetStringAsync("https://yourgame.io/config.json");
            var cfg = JsonSerializer.Deserialize<Config>(json);
            _flags = cfg.flags;
            _messages = cfg.messages;
            SaveCacheToDisk(json);
        }
        catch
        {
            LoadCacheFromDisk(); // use last-known-good
        }
    }

    public static bool IsEnabled(string name, bool defaultValue = true)
    {
        return _flags.TryGetValue(name, out var v) ? v : defaultValue;
    }

    public static string GetMessage(string name)
    {
        return _messages.TryGetValue(name, out var m) ? m : null;
    }
}

Gating a Feature

Wrap every killswitchable feature at its entry point. Show a friendly message when the flag is off.

public void OnWorldBossEventButtonClicked()
{
    if (!Killswitches.IsEnabled("world_boss_event_enabled"))
    {
        var msg = Killswitches.GetMessage("world_boss_event_enabled")
                 ?? "This feature is temporarily unavailable.";
        UI.ShowDialog("Unavailable", msg);
        return;
    }

    StartWorldBossEvent();
}

The key is doing the check before any code path that might hit the bug. If the bug is in the event’s init code, the flag check must be before init. If the bug is in the cleanup, the flag must be checked again before cleanup fires.

Fail Safe, Not Fail Open

If the config fetch fails (player is offline, your CDN is down, network times out), you have a choice: fail open (assume everything is enabled) or fail safe (keep the last known state). Always fail safe.

Cache the last successful config fetch to disk. On startup, try the fetch. If it succeeds, update the cache. If it fails, use the cache. If there is no cache (first launch), use the flag’s default value, which should usually be true for existing features and false for new ones.

Never let a failed fetch disable the entire game. That turns a network hiccup into a mass outage.

Refresh Cadence

Fetch the config on:

• Game startup — catches most players.
• Return from background — catches players who left the game running.
• Every 5 minutes while active — catches long play sessions.

Do not re-fetch every frame or every scene transition — that wastes bandwidth and slows things down. Five minutes is enough for emergency response and gentle on your CDN.

Versioning the Config

Include a version number in the config. Bump it whenever you change anything. Log the version in your telemetry so you can see which version each player is running. When you flip a switch, watch the version distribution in your logs — you will see the new version propagate across the player base in real time.

Advanced: Percentage Rollouts

Once you have the basic flag plumbing, add percentage rollouts for new features:

{
  "flags": {
    "new_matchmaking_algorithm": {
      "enabled": true,
      "rollout_percent": 5
    }
  }
}

The client hashes the player ID and enables the flag for the bottom 5% of the hash space. Ramp up gradually to 10%, 25%, 50%, 100% while watching metrics. If something breaks, ramp back to 0 instantly with the killswitch.

The Post-Incident Routine

When you use a killswitch to disable a feature:

1. Flip the switch.
2. Post an in-game notice explaining what is unavailable and why.
3. Post to your Discord/Twitter with an ETA.
4. Fix the bug.
5. Test the fix thoroughly, because you are about to re-enable something you shut off under pressure.
6. Roll out the fix, watch metrics, and re-enable the flag.
7. Write a postmortem.

The killswitch buys you time, it does not replace the fix.

“A killswitch is the cheapest insurance policy in game development. One JSON file, one fetch on startup, one flag check per feature. The first time you use it in production you will wonder how you ever shipped without one.”

Related Resources

For broader feature flag strategy, see how to set up feature flags for game releases. For handling the incident after the killswitch fires, see how to write a postmortem for a game launch. For monitoring that tells you when to pull the switch, see how to monitor game stability after launch.

Ship the killswitch machinery before you need it, not after. The moment you are in an incident is the worst time to start writing new code.