How to monitor the first week after a release

Seven days by default, because it covers a full weekly cycle including the weekend and is short enough that people remember it is open. Shorten it only for changes with no customer-visible surface. A billing change needs the window to reach the next run, and a seasonal feature needs it to reach the first real peak, so extend it only with a reason and a new closing date written in the ticket. A window with no end date is not monitoring, it is a browser tab left open.

No, and running them as one job is why post-release problems get missed. On call reacts to things that alert. Live monitoring goes looking for the things that do not: a journey that quietly completes at 54% instead of 61%, a support tag creeping up, a new error signature at ten a day. On call can hold the pager for the release, but somebody has to own the fixed-rhythm checks, the FAQ entry and the recorded decision, and that is a different piece of work. Tenhaw keeps the two apart, with the watch named on the ticket and one senior lead holding it for the window rather than a rota, under partner oversight from James Rooney.

The window opens at first real user exposure, not at deploy, and your thresholds apply to the exposed cohort rather than to total traffic. A 2% error rate inside a 5% rollout is invisible in the overall number and is still the reason to stop. Write the ramp steps into the ticket with the check you run before each one, and treat turning the flag off as the cheap rollback it is, rather than waiting to pull the whole release.

One named person on the ticket, whichever function they sit in, with a named deputy. Where Tenhaw carries that name it is on a Programme and Delivery Management engagement, and one person holds it rather than a rota. In practice the product manager tends to own the customer impact numbers, the FAQ entry and the macro, and the engineer who shipped the change tends to own the error and latency checks. Split the checklist between them if you like, but only one name carries the decision, and that person needs standing authority to roll back without convening a meeting.

Because production carries the things staging cannot rehearse: real accounts, real devices, a misconfigured flag, a missing environment variable, a CDN still serving last week's assets. That is why the first check is a person walking every key journey on production within the first hour, on the devices your users actually have, with a fresh account and a cold cache, because your own browser holds the flags and cookies that hide the fault. Watch the segments too. A fault confined to one browser, one region or one enterprise tenant disappears into a 99.6% overall success rate, so split every headline number by platform and by customer segment in the first four hours.

On a fixed rhythm, not on anxiety: one hour, four hours, 24 hours, then once a day until the monitoring window closes. Put the checklist in the ticket so a deputy runs exactly the same one: the numbers against the written baseline, new error signatures rather than raw volume, and support contacts on the tag. One new signature at low volume matters more than a familiar one at high volume. Post every result in the same channel, including when everything is flat, because a flat check posted publicly is what tells everyone the change is holding. Each check takes minutes, and if the release lands on a Friday, move it or accept that you have chosen to staff the weekend.

Record, before the deploy, the numbers you expect afterwards with today's value beside each: error rate on the affected endpoints, p95 latency, completion rate for every journey the ticket names, support contacts on the tag, and any business counter the epic is meant to move. Take the baseline from the same weekday and hour you will compare against, so Tuesday lunchtime is judged against Tuesday lunchtime. Paste the saved query or dashboard link beside each number, so the person running the four-hour check is not inventing one under pressure. Without a written prediction you will talk yourself into calling a regression seasonal variation.

When it crosses a threshold you wrote down before the release, not one negotiated during the incident. Roll back, for example, if the checkout error rate stays above 1% for two hours, or if any named journey fails outright for more than 10% of sessions. Watch, with a named fix, an owner and a date, when the movement is bounded and a fix is in reach the same day. One named person makes the call and can roll back without convening anyone. Weigh a day of bounded impact, in currency, against the planned value of the epic you would pull. If you fix forward, raise the bug anyway, because a hot fix off the ticket hides your quality signal.

Write the answer once, correctly, and early, before the first customer hits the problem and someone in support has to improvise under time pressure. For each issue found in the first week, record who is affected and how many in numbers not adjectives, such as roughly 3% of sessions or about 40 orders a day. Publish the FAQ entry in the words a customer would search for, not the words the ticket uses. Give support a macro that names the workaround and says whether a fix is coming, then have them send it live once and confirm it closed the contact without escalating. The cost of an unsupported release is paid by second line.

It can run most of it, and it should. Let an agent run the fixed-rhythm checks, diff the numbers against the written baseline, cluster new error signatures and draft the FAQ entry and the support macro. Two things stay with a person, the journey walk on production with a real account and the continue, watch or rollback decision, which needs a named owner with standing authority to act. Tenhaw builds these agents for clients against an open-source standard of 72 rules. A model reporting that the release is healthy is evidence about the build, not the live system, and a journey that fails before it emits anything looks identical to a journey nobody used. Automate the checking, keep the judgement.

Not on its own. Silence often means the new path was never instrumented, and a journey that breaks before it emits anything looks exactly like a journey nobody used. Confirm the new code is producing signal before you decide it is producing good signal, by finding the first real event from the new path and comparing its volume with the completion rate you recorded before the deploy. Dashboards tell you what broke, not that the thing works, so the check that settles it is a person walking the journeys the ticket named on production, with a real account and the devices your users actually have. Treating silence as success is how a bad release survives its first day.

Bucket every one of them before the window closes, because nothing found in live monitoring is allowed to float. A defect in shipped behaviour is a bug. Raise it and link it to the quarter's Bug Budget epic, including the one you already hot-fixed, since a fix pushed without a ticket flatters the board and wrecks the burn rate that tells you whether quality is improving or rotting. A shortcut taken to stabilise the release is tech debt, linked to the quarter's Tech Debt epic. Something the change was meant to do and never did is a missed requirement, so it becomes a story or an outcome ticket rather than a bug.

Less than teams expect, and most of it lands before the deploy. Naming the owner and the deputy, writing the baseline numbers with a saved query beside each, and agreeing the rollback thresholds all happen while nothing is on fire, and that preparation is what makes the rest cheap. Tenhaw runs the watch with the same two or three senior people who shipped the change. The checks then run on the fixed one, four and 24-hour rhythm and should take minutes each: the numbers against the written baseline, new error signatures, support contacts on the tag. The real effort sits in the journey walk on production in the first hour, and in writing the customer FAQ entry and the support macro properly.

It looks like a rule firing rather than an argument. The worked example here, an invented retailer with invented numbers, ships a guest checkout epic on a Tuesday at 13:00 against a written baseline of 0.4% checkout error rate, 910ms p95 latency and 61.5% completion. The one-hour check finds all four named journeys passing on real devices, but a 1.9% error rate concentrated in one browser's address-lookup fallback. The agreed threshold needs two hours above 1%, so 14:20 is recorded as watch with a re-check booked for 16:20. Still 1.7%, so at 16:35 the flag goes back to the previous provider, a partial rollback rather than pulling the epic, and it is 0.6% by 17:00.

Three lines in the ticket of your next release, all written before the deploy. Tenhaw publishes all seventeen guides free to adopt. One: a named owner, a named deputy and the date the window closes, seven days out by default. Two: the numbers you expect afterwards with today's baseline and the saved query beside each, taken from the same weekday and hour you will compare against. Three: the threshold that would trigger a rollback, and who can call it without convening anyone. That alone catches most of what teams miss. Add the fixed-rhythm checks on the release after that, then the customer FAQ entry and the support macro. One release watched properly teaches a team more than a process document ever will.

Almost certainly not. Tenhaw runs this watch on a client's existing dashboards. The kit is the dashboards and saved queries you already have, named and linked in the ship kit so the person running the four-hour check is not inventing a query under pressure. What teams actually lack is simpler, a real production account rather than a seeded one for walking the journeys, and the devices your users have rather than the laptop the change was built on. Log in clean, with nothing cached, because the browser you have been developing in will hide the fault. If a number genuinely is not visible, the gap is usually instrumentation on the new code path, not your tooling budget.

In The Tenhaw Way, five things, all evidenced on the ticket. Every key journey the shipped ticket named has been walked on production by a person, with the screenshots stored against the ticket. A continue, watch or rollback decision is recorded with its timestamp, its owner and the numbers it rested on. Every defect found is linked to the quarter's Bug Budget epic and every stabilising shortcut to the Tech Debt epic. The customer FAQ entry and the support macro are published and have answered a real contact without escalating. Then the window closes with a written note, and the parent epic moves into value monitoring or is held with a stated reason and a date.