What to check after a release: the first day in production for an analyst

After a deploy, plenty of people watch the system: errors, load, response time. Almost nobody watches whether its behaviour matches the spec on real data. This is the last place in the chain where a requirement can still be checked against reality before users find the divergence — and it falls to the analyst simply because there is nobody else.

A deploy is not yet a release

Russian speech uses one word for both; in the work they are two events. A deploy means the code is on the server. A release means the behaviour has reached the user. If a feature flag separates them, there are two first days as well, and each has its own checks.

• After the deploy, flag off. You check that nothing has changed. The code sits on the server silently, and if behaviour did change after all, the flag does not cover everything.
• After the flag is switched on. You check that exactly what the spec describes has changed, and only for those it should have.

The check plan is written in advance

The list of what to watch after a release is drawn up not on deploy night but when the acceptance criteria are written. At night it is too late to recall which data is affected and where to look for confirmation.

The last row is the one most often forgotten. An adjacent system often pulls data once a day, and a divergence there shows up only the next morning. That is why the first day is a day and not the first hour.

Old data is the main source of surprises

On a test environment the data is fresh and tidy. In production there are records created under earlier rules, with years of accumulated edge cases: unclosed periods, manual corrections, fields that used to be optional.

In the subscription example the renewal rule changed. The question that will certainly come up: what about subscriptions paid for before the release? Renew them under the new rule, the old one, or from the payment date? If the spec is silent, that is an omission, and the one who finds it will not be a tester but the first user with an old subscription.

Ask about old data at spec time. One line — “records created before the release are handled like this” — removes most of the first day’s surprises. If there is no such line, the first item of the check plan becomes a sample of old records.

Rollback is decided before the deploy

At night, with the first worrying tickets coming in, a rollback decision is made under pressure and by guesswork. It is more sensible to write the condition down in advance: which observation means rolling back the code or switching off the flag.

The analyst has a particular question here, because a rollback undoes code, not data. If the data was already transformed during the deploy, returning the code will not bring it back. Whether the change is reversible has to be known before the release, not discovered after it.

If a hotfix is made instead of a rollback, its change has to make it back into the spec. Otherwise the next planned version overwrites the fix and the story repeats.

The release card

All of this fits into a short record next to the task. It is kept up during the first day, not written from memory at the end:

RELEASE 2026-09-24   subscriptions, REQ-114 rev. 3
  flag       renewal_from_period_end, on at 09:00
  checked    09:15  control subscription renewed from the end date
             12:00  sample: 214 renewed, 0 under the old rule
             next day 10:00  revenue report agrees with billing
  old data   paid before 24 Sep renew under the new rule
             (product owner decision, 22 Sep)
  rollback   if any renewals under the old rule — switch the flag off
  result     tickets on the topic in 24 hours: 0

The “rollback” line is written before the flag goes on. The “result” line is the only one that can be filled in only at the end.

Warn support

Support is a sensor no monitoring can provide: it sees how people perceive the behaviour. But the sensor works only if it knows what has changed.

Otherwise, for the first day, support answers “that’s a bug, passed to the developers” to what was intended, and cannot tell a real error from the new behaviour. A short message before the release is enough: what changed, what the correct new behaviour looks like, where to bring questions.

A task is finished not when the code is deployed, but when someone has looked at what it does with real data.

How the first day ends

The result is recorded in the task: what was checked and how it turned out. This closes the traceability chain: the requirement now has not only a test but a confirmation in production.

Every surprise of the first day is filed as a defect with its kind and a link to the requirement. The omissions among them are direct material for the next spec.

A fifteen-minute check

Recall the last release and answer three questions. Was there a written plan of what to watch after the deploy? Who specifically watched? Which observation would have triggered a rollback? Wherever the answer is “nobody” or “don’t know”, that is where to start.

What next

This is where the chain closes. What surfaced in the first day — omissions, forgotten old data, an adjacent system nobody thought of — becomes the input to the next task. And its readiness is worth checking with what you have just learned in mind.