An urgent, minimal fix pushed straight to production outside the normal queue to stop something actively breaking.
Why it exists
Sometimes a serious bug is already live and cannot wait for the normal release cycle, which is too slow for an emergency. A hotfix exists as an urgent, narrowly scoped fix pushed straight to production, so a critical problem gets patched now and the proper process resumes after.
How it actually works
Normally changes flow through review, testing, and scheduled releases. A hotfix is the emergency lane: a small, targeted fix for a live, painful problem, fast-tracked with just enough checking to be safe.
It's deliberately minimal, change as little as possible to stop the bleeding, precisely because it's skipping some of the usual safety steps.
A senior PM walks you through it
A junior PM, stuck
Checkout is crashing for anyone who applies an expired coupon, and the lead just said hotfix going out in 20 minutes and asked me to sign off. I know a hotfix skips steps, so it feels risky, but I cannot tell if this one is a reasonable emergency or a rushed change that will make things worse.
The word hotfix is not the risk, the diff is. A hotfix is the emergency lane, and whether it is safe comes down to how small and how contained the change is, plus which safety steps got skipped. All of that is on the PR. This is the actual emergency PR and the incident note. Read it, then take the steps with me and you will be able to judge the risk yourself.
PR: HOTFIX: expired coupon crashes checkout
PR
Author: Rafi Base: production Label: hotfix
Diff: 2 lines changed in the coupon path, checkout.ts
- if (coupon.discount) applyCoupon(coupon)
+ if (coupon && !coupon.expired) applyCoupon(coupon)
Approvals: 1 (expedited). Normal rule is 2. Full QA skipped, unit tests passed.
Slack #incident
Nadia Checkout crashes for anyone applying an expired coupon. Declaring an incident.
Nadia Bug reported 15:40, Rafi's PR opened 15:48, approved 15:55, live 16:05. About 25 minutes end to end.
Click a step to see the lines it points at.
Mistakes I've seen
Judging a hotfix by how urgent it feels instead of by the diff. Urgency is why it skips the queue, but only the size and reach of the change tell you whether skipping was safe.
Waving through a hotfix that quietly rewrites half of checkout. The label says minimal, the diff is the truth, and a large change on the emergency lane is the dangerous case.
Skipping the follow-up ticket once the bleeding stops. A hotfix trades thoroughness for speed on purpose, and without a scheduled proper fix with tests the gap it left never gets closed.
Signing off without checking the change is scoped to the broken path. A fix that reaches beyond the coupon logic is no longer a narrow hotfix, and that is exactly what the skipped QA would have caught.
Sign off with the reasoning out loud: "The diff is 2 lines on the coupon path, unit tests pass, one approval and QA skipped. Scope is small enough that the hotfix is a reasonable risk. Ship it, and file the follow-up for a proper fix with full tests." You judged an emergency change by its blast radius, which is how you read every hotfix that lands on your desk.
Where a PM meets this
"We'll hotfix it" means the problem is bad enough to bypass the normal process; recognizing that signals real urgency.
Hotfixes carry more risk (less testing); a follow-up proper fix usually comes after.
Hear it in a meeting
"Hotfix is going out now for the checkout bug, proper fix lands tomorrow."