Most deploys go fine. The ones that don't tend to show a problem within minutes, or in a nightly job that fails the next morning. The first 15 minutes after a deploy are when you can still link a problem to the change you just made, so it's worth spending them on a short, fixed check.
This post sets out four checks, a plain rule for rolling back, what to say if customers are affected, and a checklist you can paste into your task list.
Why the first 15 minutes after a deploy matter for a small team
A small team often has one or two people who deploy, and the same people who then get on with other work. Nobody is watching a dashboard all afternoon. If a deploy breaks the homepage, a checkout form or a background job, the first sign is often a customer email or a message from a client.
A short check straight after the release catches most of the obvious problems while the change is still fresh in your mind. It also gives you a record of what you looked at, which helps if something goes wrong later.
The checks below use the monitors you already have in AperioFlow: HTTPS monitors, heartbeat monitors for cron jobs and backups, the error list and your status page. If you are setting these up for the first time, our post on how to monitor a site and what to alert on covers the settings to choose before you start.
Check one: is the site up?
Open your HTTPS monitors and look at the latest check on each one. Start with the pages that matter most to customers: the homepage, sign-in, and any page where people pay or submit a form. A single failed check does not always mean the site is down. Each monitor has a failure threshold you set, so it alerts only after that many failed checks in a row. Look at the check history, not just the status badge, so you can see whether failures have started since the deploy.
The same HTTPS monitor also checks the site's certificate. If a deploy changed the web server or the way certificates are installed, that can show up here too, so take a moment to confirm nothing has changed in that area.
If a monitor has started failing right after the release, treat it as your first lead and move on to the other checks to see how far the problem reaches.
Check two: is the error list growing?
Next, open the error list and compare it with how it looked before the deploy. One error on its own is often noise. What you are looking for is a new pattern: the same error repeating, especially one that did not appear before the release.
Ask three questions. Is this error new since the deploy? Is it happening to many users or only to one? Does it sit on a page or action that changed in this release? If the answer to all three is yes, you have a probable cause and a place to start.
If the list is quiet, that is useful too. Write down that you checked it and found nothing new. That note matters if a customer reports a problem later.
Check three: did your scheduled jobs still check in?
Deploys often break things that run out of sight: nightly exports, backup scripts, invoice runs and report emails. A heartbeat monitor works the other way round. The job checks in each time it succeeds, and you get an alert when a check-in is late. If a deploy changed a path, an environment variable or a dependency, a job can stop running without any error reaching the error list.
After a release, look at the heartbeat for each job that runs on a schedule. Check that the most recent check-in is inside the window you expect. If the job is due to run tonight and you want to be sure, run it by hand now and confirm that the check-in arrives.
Backups deserve particular attention. A backup that stops quietly is one of the more expensive surprises a small team can have, so do not skip this step even when the rest of the deploy looks clean.
Check four: is the site slower than before?
Finally, compare response times with the figures from before the deploy. Slow is not the same as down. A site can pass every up check and still feel wrong to the people using it. A new database query, a larger image or a missing cache can add seconds to a page without ever returning an error.
Use your monitor history to compare the time before and after the release. If you have a rough baseline, look for a clear step change rather than a single slow check. A one-off slow response from a monitor is common; a sustained rise after the deploy is worth investigating.
If you find a slowdown but the site is working, you usually have time to plan a fix rather than an emergency rollback. Note the page, the change and the figures, and add it to your task list.
When to roll back and when to fix forward, in plain terms
Roll back when customers cannot complete the main thing your site does, and you cannot see a fix within a few minutes. Examples include sign-in failing for everyone, a checkout that will not load, or a backup job that has stopped with no clear cause. Rolling back is usually the faster route to a working site, and you can look at the change properly once things are stable.
Fix forward when the problem is small, contained and clearly understood. A typo on one page, a single broken link or a slow report that does not affect sign-in or payments can often be fixed with a quick follow-up release. Make sure the fix is tested against the same checks you ran after the original deploy.
If you are not sure, roll back first and investigate second. A short period on the previous version is easier to explain to customers than a longer period of broken pages while you experiment.
If customers are affected, post a short update on your status page
If customers can see the problem, tell them. Post on your status page as soon as you have confirmed the issue, and keep updates short. Our post on what to put in an incident update covers the detail. For a quick first post, the five-line template below is enough.
- What is affected, in plain words: for example, 'Sign-in is failing for some users.'
- When it started, in local time and date: for example, '14:20 on 3 March 2026.'
- What you are doing now: for example, 'We have rolled back the latest release while we investigate.'
- What customers should do, if anything: for example, 'Your data is safe. You do not need to take action.'
- When the next update will come: for example, 'We will post again by 15:30.'
Update the page when the situation changes, and say when it is resolved. Do not promise a time for a fix you have not confirmed. If the issue affects a specific group, such as one payment method, say so.
A copyable checklist to paste into your task list as a recurring task
Set this up as a recurring task that you attach to every release, or as a template you copy each time. Adjust the names of the monitors and jobs to match your own setup.
- [ ] Check the latest check and the recent history on each HTTPS monitor, starting with homepage, sign-in and checkout
- [ ] Open the error list and compare it with the state before the deploy; note any repeating error
- [ ] Confirm each scheduled job and backup has checked in within its expected window
- [ ] Compare response times for key pages with the figures from before the release
- [ ] Decide: roll back, fix forward, or monitor for another hour
- [ ] If customers are affected, post a status page update using the five-line template
- [ ] Record what you checked, what you found and the time you finished
If you want the monitors, heartbeats and error list in one place before your next release, you can set them up on the free plan, which includes 10 monitors. Start free at https://app.aperioflow.co.uk/#/signup
For the next steps, our posts on setting up your first monitors, on heartbeat monitors and on error triage go into more detail on each part of this check.