A hotfix is an urgent patch applied directly to a production release to fix a critical bug, without going through the normal development cycle. The name reflects the intent: it is applied while the system is “hot” (running in production) and cannot wait for the next scheduled release.

In a typical workflow using release branches:

main:    A --- B --- C --- D  (development continues)
                \
release/1.2:    X --- Y  (currently in production)
                      |
hotfix/1.2.1:         Z  (fix applied here)

The fix is made on the release branch (or a hotfix branch off it), tested, deployed to production, then merged back to main so the fix is not lost in the next release.

Hotfixes are for critical failures: a security vulnerability being actively exploited, a payment processing bug causing data loss, or a crash that affects all users. They bypass the normal QA and review process, which means they carry higher risk of introducing new problems. The goal is to minimise the time the production system is in a broken state, accepting that the hotfix itself may need a follow-up.

The most common mistake with hotfixes is forgetting to merge them back to main. A fix applied only to the release branch will be silently undone in the next release. The second mistake is treating hotfixes as a normal development path — if the team is frequently hotfixing, the CI/CD pipeline and testing practices need attention, not the release schedule.