Hotfix

The word arrived once shipping got a schedule. When a team agrees to deploy every two weeks on a fixed day, it can close the scope in advance and leave real time for review. That predictability is most of the value.

The trouble starts when a problem shows up that the schedule will not wait for. Say the day after a release someone finds that cards can no longer be registered on the payment screen. The next release is thirteen days out, and every person who meant to upgrade in that window walks away instead. Ten a day makes a hundred and thirty over thirteen days, and none of them come back.

Pagedeck lived that scene before it had a name for it. Sofia reported that a customer could not pay, Theo answered that the next deploy was Tuesday of the following week, and then half an hour disappeared while nobody could work out who was allowed to approve an exception. Everyone knew what the fix was. There was no route to ship it.

A hotfix is that route, cut in advance. The team defines one exception path, to be used only when the cost of waiting is clearly larger than the risk of skipping steps, and writes down the conditions for opening it ahead of time rather than arguing about them while the service is down.

Start by deciding whether this incident can wait for the normal schedule. Only when the answer is no do you walk the six steps below.

1. Assign a severity. Severity is the grading of how much a defect affects the service. Money not moving, data disappearing, and information leaking to the wrong account sit at the top grade, and only the top grade earns a hotfix. A slightly broken layout waits for the next cycle.
2. Write the change down in one line. Name the single thing being fixed and let nothing else on board. "While we're deploying anyway" is the most reliable way to turn one incident into two.
3. Branch from the code that is running right now. If the fix is stacked on the code being prepared for the next release, everything else sitting in that branch ships with it, reviewed or not. Cut from the version that is live and apply the fix only there.
4. Run a shortened check, not an empty one. What normally takes a day gets compressed into an hour. Code review still needs at least one other pair of eyes, and quality assurance (QA) — the work of checking quality before something ships — covers the fixed area and what surrounds it. A CI/CD setup, which chains automated verification to deployment, keeps this step off people's hands.
5. Ship it and watch. Go out holding a way back. For the next thirty minutes, watch the error volume and the usage numbers for that screen, and if they do not recover, roll back.
6. Replant the fix on the main line and write it down. A fix applied only to the live branch does not exist in the code being prepared for the next release. Skip this and the same bug returns in two weeks. If users need to hear about it, it goes in the release note, and if the incident was large enough it earns a postmortem recording the cause and what changes because of it.

Step 6 is the one teams actually miss, because once the fire is out everyone goes back to what they were doing. A common rule is that whoever shipped the hotfix finishes the merge back to the main line the same day.

Use it when every hour of waiting turns directly into loss: payments blocked, logins blocked, user data being deleted, one account seeing another account's content. At Pagedeck a payment outage empties a full day of revenue, and a document visible to the wrong account adds affected users for as long as it stays live.

It does not apply to problems with a workaround. A button in the wrong place or a list sorted backwards is annoying, but people can still do their work. Adding a feature never ships this way either, however badly someone wants it.

Three limits are worth knowing.

1. You are switching off your own filters. The review and the waiting that make a normal release slow are the net that catches mistakes. Ship without the net and you find out afterwards that the fix broke something else. This is why one hotfix so often produces a second one.
2. It costs people. A late-night deploy pulls in someone to write the fix, someone to review it, and someone to watch the result. Having an on-call rotation — the person whose turn it is to take outage calls — does not mean one person covers it.
3. Frequency erodes the schedule. A team shipping five hotfixes a month is really deploying through the exception path, and the checks attached to the regular release stop meaning anything. At that point the thing to fix is not the hotfix procedure but why that many bugs are reaching production.

"This goes out as a hotfix. Payments have been down for forty minutes."

Shipping now instead of waiting for the cycle, with elapsed time as the justification.

"Don't put that on the hotfix. One fix only."

Blocking an unverified change from riding along on a deploy that skipped verification.

"Did the hotfix get merged back into main?"

Checking that a fix applied only to the live branch has not vanished from the next release.

Here is how it played out at Pagedeck. At four on a Friday afternoon Sofia reported the same payment error from three customers, and Mia graded it top severity and called a hotfix. Theo branched from the version running in production, changed one line, and another engineer finished the review in fifteen minutes.

The deploy finished at 5:20, and nobody left until thirty minutes of watching showed the payment success rate back at its usual level. The following Monday Mia ran a review of why the bug got through the normal checks in the first place.

The most common misreading is that a hotfix is simply "the fast way to deploy." It is fast, so that is easy to believe. But speed is the result; the thing itself is an exception with steps removed. Once speed becomes the reason for using it, changes that were never urgent start taking the same path, and within six months the regular release is a formality — and when something does break, nobody can say what shipped when.

The other one is treating a hotfix as strictly better than a rollback. Reverting feels like retreat and fixing forward feels like progress. In practice, a fix written before the cause is understood ships without anyone having confirmed it is the right fix. When the cause is clear and the change is one line, the hotfix is faster. When the cause is not clear, revert first to stop the bleeding and investigate afterwards.