A hotfix is a software update released outside the normal release cycle to fix one urgent problem in software that's already live. It's small, it targets a specific bug or vulnerability, and it ships as soon as it's ready instead of waiting for the next scheduled release. The name comes from patching a hot system, meaning a production server that's actively serving users.

What is the difference between a hotfix and a patch?

A patch is any update that changes existing software, whether it fixes bugs, closes security holes, or updates drivers, and it usually ships on a schedule. A hotfix is a patch with urgency attached: it fixes one critical problem and is released immediately, outside that schedule. Every hotfix is a patch, but most patches aren't hotfixes.

What is the difference between a hotfix and a bugfix?

A bugfix is any change that corrects a defect; a hotfix is an urgent way of delivering one. The same fix can ship with the next planned release or go out on its own as a hotfix. What changes is the process: a hotfix skips the queue and goes to production by itself, usually from a dedicated branch, with testing focused on the affected behavior.

What is a hotfix in gaming?

In online games a hotfix usually means a change the developer applies on the server, so players get it without downloading anything. Blizzard describes World of Warcraft hotfixes as updates made without requiring a new client-side patch. A game patch, by contrast, is a download that changes the files on the player's machine.

How do you version a hotfix in semantic versioning?

A hotfix that only contains backward-compatible bug fixes increments the PATCH number: a hotfix to 2.4.0 is 2.4.1. Semantic Versioning has no separate hotfix number, and a fourth digit such as 2.4.0.1 isn't a valid semantic version. If the fix has to go to an older release line as well, that line gets its own patch bump, for example 1.9.3 to 1.9.4.

What is a hotfix branch?

It's a short-lived Git branch created from the code that's running in production, used to make one urgent fix without pulling in unreleased work. In the Git flow model it branches off the main branch and is merged back into both main and develop, then deleted. Teams doing trunk-based development fix the bug on trunk first and cherry-pick the commit to the release branch.

Hotfix: Meaning, Hotfix vs Patch vs Bugfix, Versioning

A hotfix is a software update released outside the normal release cycle to fix one urgent problem in software that’s already live. It’s small, it’s targeted, and it ships the moment it’s ready — nobody waits for the next scheduled release when checkout is down or customer data is exposed.

The word comes from operations. Originally a hotfix meant patching a hot system — a production server that was actively serving clients — and the meaning has since widened to any fix that’s built with urgency and released off-schedule. That’s the definition; the rest of this guide covers what the definition leaves out, which is how a hotfix differs from a patch and a bugfix, what version number it gets, which branch it comes from, and what to tell users once it’s out.

Jump to: Hotfix vs patch vs bugfix · In gaming · When to hotfix · Version numbers · Hotfix branches · With release automation · Release notes

Hotfix vs patch vs bugfix

These three words describe overlapping things, which is why they get mixed up. The cleanest way to separate them is to ask what each one is about: a bugfix is about the code, a patch is about the delivery, and a hotfix is about the urgency.

Term	What it is	When it ships	Typical trigger
Bugfix	A code change that corrects wrong behavior	Usually with the next planned release; urgent ones go out as hotfixes	Any bug, at any severity
Patch	An update that modifies existing software — fixes, security updates, drivers	Usually on a schedule	A batch of fixes is ready
Hotfix	One urgent fix released on its own	Immediately, outside the schedule	An outage, data loss, or a security hole in production
Coldfix	A fix applied during planned maintenance, often with downtime	In a scheduled window	A problem that can wait for the window

A few things follow from that table:

Every hotfix is a bugfix, and every hotfix is a patch. The reverse isn’t true. The bug that makes a button two pixels off-center gets a bugfix; the bug that double-charges customers gets a hotfix.
“Hot” used to mean “no restart.” In the older, stricter sense a hotfix is applied to a running system without downtime, and its opposite is the coldfix, which needs users logged out or systems rebooted. You’ll still see that distinction in enterprise IT writing. Most software teams now use “hotfix” for the urgency alone.
Vendors bend the word. Microsoft used “hotfix” and “quick-fix engineering update” (QFE) for years as names for narrowly targeted fixes. Its current update terminology no longer has a hotfix entry of its own — the word survives only inside the definitions of service packs and update rollups, which bundle earlier hotfixes together.

What “hotfix” means in gaming

A large share of people searching this word are players reading patch notes, and games use it in a specific way. A game hotfix is usually a change the developer makes on the server, so it reaches players without a download. Blizzard’s World of Warcraft notes spell it out: “Hotfixes are updates made without requiring a new client-side patch.” Some of them take effect the moment they’re implemented.

A game patch, by contrast, is a client download that changes the files on your machine. That’s why a balance tweak can appear mid-week with no update prompt, while new content arrives as a multi-gigabyte patch. It’s the same split as the table above — urgency and delivery method — applied to a product where the server and the client update separately.

When a bug deserves a hotfix

A hotfix is expensive in ways that don’t show up in the diff. It interrupts whatever the team was doing, it gets validated under time pressure, and it has to be merged back carefully or the bug returns later. So the first question isn’t “how do we hotfix this?” but “does this need one?”

The bugs that usually qualify:

Something core is unusable — login, checkout, the editor, the API endpoint most customers depend on.
Data is being lost or corrupted, and every hour makes the cleanup bigger.
There’s an exploitable security vulnerability.
Money is wrong — double charges, missing invoices, incorrect totals.
You’re in breach of a legal or contractual obligation until it’s fixed.

Everything else can wait for the next release, and for teams that deploy several times a day that wait is hours anyway. There are also two cheaper tools worth trying before a hotfix:

Roll back. If the bug arrived with the last deploy and the deploy is reversible, going back to the previous version restores service faster than writing new code under pressure. A database migration that can’t be reversed is the usual reason this isn’t an option.
Turn the feature off. If the broken code sits behind a feature flag, flipping it is a one-line change that needs no deploy at all.

A hotfix is what you reach for when neither is enough: the bug is old, the rollback would lose data, or the broken thing can’t be switched off. A rollback or a flag can also just buy time — it restores service while you prepare the permanent fix.

How to version a hotfix

Under Semantic Versioning, a hotfix is almost always a PATCH release. The spec says the patch number “MUST be incremented if only backward compatible bug fixes are introduced,” and that describes nearly every hotfix: a hotfix to 2.4.0 ships as 2.4.1. Urgency doesn’t change the rules, though — if the fix breaks the public API, it’s still a MAJOR bump.

The word “hotfix” doesn’t appear anywhere in the SemVer spec, because the version number describes compatibility, not how stressful the release was. Three things trip teams up here.

There’s no fourth number. 2.4.0.1 looks like a natural home for a hotfix, but a semantic version has exactly three numeric parts. npm, for one, requires every version to be parseable as SemVer, so a four-part number can’t be published there at all.

Build metadata isn’t a hotfix marker. 2.4.0+hotfix.1 is valid SemVer, but the spec says build metadata “MUST be ignored when determining version precedence.” It has the same precedence as 2.4.0, so don’t count on it to signal an upgrade — use a new patch version.

Never re-release the same number. It’s tempting to rebuild 2.4.0 with the fix and quietly replace the artifact. SemVer forbids it — “Once a versioned package has been released, the contents of that version MUST NOT be modified” — and for good reason: two different builds with one version number make every bug report ambiguous.

When the fix has to reach more than one release line, each line gets its own bump. If 2.4.0 is current and you still support 1.9.x, the same fix ships as 2.4.1 and 1.9.4. The semantic versioning guide has the full rules, including what to do when a “fix” turns out to break compatibility.

Hotfix branches in Git

The branching question is really one question: how do you ship a fix for what’s in production without also shipping the half-finished work that’s been merged since? The answer depends on your workflow.

Git flow

Vincent Driessen’s Git flow model is where the term “hotfix branch” comes from. Its rules are short:

A hotfix branch branches off master (or main), because that’s what’s in production.
It’s named hotfix-*, typically with the version it will become.
It merges back into both master and develop, so the fix isn’t lost when the next release is cut.
If a release branch is open at the time, the hotfix merges into that release branch instead of develop.

In commands, a hotfix for 1.2.0 looks like this:

git checkout -b hotfix-1.2.1 master
# fix the bug, bump the version, commit
git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1
git checkout develop
git merge --no-ff hotfix-1.2.1
git branch -d hotfix-1.2.1

One caveat from the author himself: in a note added in 2020, Driessen says Git flow was designed for explicitly versioned software, and that teams doing continuous delivery of a web app should adopt a simpler workflow instead.

Trunk-based development

With one long-lived branch there’s nothing to branch from in the Git flow sense. If you deploy straight from trunk, a hotfix is just a small pull request that gets reviewed and deployed ahead of everything else.

If you cut release branches from trunk, the trunk-based development guidance is strict about direction: reproduce the bug on trunk, fix it there with a test, and then cherry-pick the commit to the release branch. Don’t fix it on the release branch and plan to copy it back, because the copy-back is the step that gets forgotten at 2 a.m. — and forgetting it means the bug reappears in the next release.

When you cherry-pick, use -x:

git checkout release/2.4
git cherry-pick -x <sha-of-the-fix-on-main>

The flag appends “(cherry picked from commit …)” to the message, which the Git documentation calls useful for exactly this case — backporting a fix to a maintenance branch — because the two commits stay traceable to each other.

A note on commit messages

If you use Conventional Commits, a hotfix commit is fix:, not hotfix:. The spec allows other types, but hotfix isn’t in the default type list of the standard commitlint ruleset, so it gets rejected, and release tools give it no meaning. fix: is what tells them to cut a patch version. If the fix is breaking, mark it with ! or a BREAKING CHANGE footer.

Hotfixes with release automation

Tools that compute the version from commits handle the common case for free: merge a fix: commit to the release branch and, if nothing bigger is waiting unreleased, the next release is a patch. The harder case is a hotfix for a version that isn’t the latest.

semantic-release covers it with maintenance branches. Its default configuration already treats branches named like 1.x or 1.0.x as release lines. The documented recipe is to create the branch from the old tag and commit the fix there:

git checkout -b 1.0.x v1.0.0
# commit "fix: a fix", then push

semantic-release publishes 1.0.1 on its own distribution channel, so users on latest aren’t moved backwards. The semantic-release guide covers the branch rules in more detail.

Release Please does it by pointing the action at more than one branch. The action’s README shows the pattern — trigger on each release branch and pass the branch name as the target:

on:
  push:
    branches:
      - main
      - 1.x
permissions:
  contents: write
  pull-requests: write
  issues: write
jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
        with:
          release-type: node
          target-branch: ${{ github.ref_name }}

The permissions block is what lets the default token open the release PR and create the release; the repository also needs “Allow GitHub Actions to create and approve pull requests” switched on in its Actions settings. A fix merged to 1.x then gets its own release PR against 1.x. Setting versioning-strategy to always-bump-patch on that branch keeps a stray feat: commit from turning a maintenance line into a minor release; the Release Please guide explains the option.

How to write a hotfix release note

A hotfix gets shipped quickly and announced badly, or not at all. That’s a mistake, because the people affected by the bug are exactly the ones watching for news — and a silent fix leaves them unsure whether it’s safe to come back.

A hotfix note needs four things, and none of them takes long:

What was broken, in the user’s words. “Exports failed for workspaces with more than 10,000 rows,” not “Fixed null pointer in ExportService.”
Who was affected and since when. This lets everyone else stop reading, and tells the affected group you understand the scope.
That it’s fixed, and in which version. Include whether the user has to do anything — update, refresh, re-run the job.
What to do about the damage. If data needs re-importing or an invoice needs correcting, say how.

Here’s the difference in practice:

Before: Bug fixes and stability improvements.

After: 2.4.1 — Fixed: CSV exports failing on large workspaces. Since Tuesday’s release, exports from workspaces with more than 10,000 rows ended with an error instead of a file. That’s fixed in 2.4.1, which is live for everyone now — no action needed. Exports that failed weren’t queued, so you’ll need to run them again.

In a changelog that follows Keep a Changelog, the entry goes under Fixed, or under Security if it closes a vulnerability. If the hotfix replaces a release so broken that you pulled it, mark the old one [YANKED] — the format asks for that tag to be loud so nobody installs the withdrawn version by accident.

Two more habits are worth having. For security hotfixes, describe the impact and the fixed version but hold the technical detail until users have had time to update. And when the fix is a one-liner that the team would rather forget, resist the urge to hide it inside the next big release’s notes; the guide to what to write instead of “bug fixes and performance improvements” has more before-and-after examples for exactly this kind of entry.

The short version

A hotfix is one urgent fix released outside the normal cycle. A bugfix is any fix, and usually waits for the next release; a patch is the general word for an update to existing software.
In games, a hotfix is usually a server-side change with no download.
Try a rollback or a feature flag first. Hotfix when neither is possible.
In SemVer a backward-compatible hotfix is a PATCH bump — 2.4.0 to 2.4.1. No fourth number, no reusing the old one.
Branch from what’s in production, and make sure the fix lands on your main line too. In trunk-based development, fix trunk first and cherry-pick.
Announce it. Say what broke, who was affected, which version fixes it, and what users need to do.

ReleasePad drafts release notes from the work your team already did, so a hotfix can be announced as soon as it ships — you review the draft and press publish. The GitHub integration drafts entries from your commits and pull requests, and you publish them to a public changelog page and an in-app widget. Try it free →

What Is a Hotfix? Meaning, Hotfix vs Patch vs Bugfix, and How to Ship One