hotfix

A hotfix is an urgent, narrowly scoped software change shipped to production outside the regular release cycle to repair a critical bug or security issue in a live system. The change is deliberately small, often a single file or a single configuration value, so the team can get from incident to production in hours instead of the days a normal release would take.

A hotfix usually starts inside an error budget burn or a security advisory and leaves behind a short version-control trail like this one:

21:04  pager: 500s spiking on /checkout (sev-2)
21:10  branch hotfix/checkout-500 cut from tag v2.4.7
21:24  PR #4821 opened, one-line null check on cart["coupon"]
21:38  CI green, two approvals, merged to main
21:42  v2.4.8 tagged and deployed to production
22:01  500 rate back to baseline, incident closed

How It Shows Up in Practice

A Python developer encounters a hotfix as a short-lived branch named something like hotfix/checkout-500 or hotfix-2.4.8, cut directly from the production tag rather than from the current tip of main. That isolation matters because main often contains half-finished work that doesn’t belong in front of users tonight, so the fix has to ride on top of the exact code that is running.

The branching pattern was first formalized in Gitflow, the model Vincent Driessen described in 2010 and now a legacy workflow that trunk-based development has largely replaced. In Gitflow, hotfix branches branch off main, the branch that records the official release history, merge back into both main and develop, and bump only the patch component of the version number. Teams using version control on a single trunk apply a slimmer version of the same idea: cherry-pick the fix onto a release branch, ship it, and then forward-port the same commit to main.

The version bump itself follows the rule from semantic versioning, which reserves the patch component for backward-compatible bug fixes, so the fix takes v2.4.7 to v2.4.8.

A patched release tagged v2.4.8 then flows through the same continuous-delivery pipeline as any other version, with one difference: the team usually runs the smoke and regression suites at full speed and skips slower nightly checks to land the fix faster.

Common Pitfalls

The same pressure that makes a hotfix necessary is what makes hotfixes go wrong. Three failure modes recur often enough that most teams capture them in a runbook or an architecture decision record on release process:

Skipping the merge back to main: the fix ships from a release branch, the incident closes, and the follow-up pull request never lands. The next regular release goes out without the patch, the bug returns in production, and on-call gets paged again. Some teams add a CI check that blocks a release tag whose changes aren’t also present on main, but nothing in Git or Gitflow enforces the merge-back for you.
Bypassing review and CI: a senior engineer pushes the fix directly to the release branch under time pressure. The change is correct, but it accidentally drops a config flag, and the rollback ends up harder than the original bug. The mitigation is to keep CI mandatory and require a second approver even on a one-line diff.
Letting the hotfix grow: while shipping the fix, somebody adds a small refactor since the file is already open. The scope expands, the risk profile changes, and the change is no longer a hotfix but a normal release wearing a hotfix label.

The closest concept that isn’t a hotfix is a regular patch release, which carries the same patch-level version bump but rides the normal cadence and full test matrix. When the urgency rather than the diff size is what makes the change necessary, the right label is hotfix.