Peak season & code freeze
From roughly the first week of November to the second week of January, your change stops. Nobody else's does.
A code freeze is a good practice and it addresses exactly one category of risk: the change you control. Meanwhile the analytics vendor ships on their own calendar, the tag manager has editors in marketing who were never told about the freeze, and the support widget updates itself.
So the freeze reduces your own deploy rate to nearly zero while third-party change continues at its normal weekly rate, which means that during the eight weeks your revenue is most concentrated, almost every change on your checkout page is a change you did not make. We wrote about that in code freeze is a security event.
What makes it worse than the rest of the year
- The people who would notice are the people most likely to be on call rather than at a desk.
- Traffic anomalies stop being anomalies. Card testing is genuinely hard to see against a Black Friday baseline.
- Nobody wants to touch anything, which is correct, and which also means a suspicious script tends to stay up while a decision is deferred.
What applies here
Checkout Monitor, with the baseline locked before the freeze begins. The inventory you agree in October becomes the thing every November change is measured against.
Account Defense matters more in this window than any other, because a card-testing run hides inside seasonal volume in a way it cannot in March.
A sensible October
- Run the inventory while people still have time to explain what things are.
- Get the tag manager's editor list down to who it should actually be. This is usually the highest-value hour of the whole exercise.
- Decide, in advance and in writing, who can approve removing a script during the freeze. Deciding that in the moment is how a script stays up for six days.
Related
Code freeze is a security event · Card testing looks like a good day