Check seven things before you pick a release date,and say it out loud only when they pass.
Most release planning goes wrong in a quiet way. The code is fine, the date is reasonable, and then it turns out the person who signs off is out the day before, or on-call is a new hire on a long weekend. Nobody hid anything. Nobody asked the right question before the date was announced.
This is the release checklist I run before I say a date to anyone. It isn't about tests or feature flags; you have those. It's about people: who has to be around before, on and after the release date, what exactly to ask each of them, and what to do when the answer is "they're out." You can plan a release around PTO and holidays, but only if you check before the date has a life of its own.
My rule is simple. The date doesn't leave my head until every check passes. Once it's in a Slack message, marketing has it, a customer has it, and moving it costs a conversation instead of a click.
The ten-minute version
Before the date goes anywhere, block ten minutes. Look at the release date plus the two working days before it and the three after it. For each of the seven checks below, write down a name or an answer: the release owner and backup, who signs off, who's on call, who leads support, who wrote the riskiest change, which outside approvals you're waiting on, and any holiday or team period in that window. Anything you can't answer from the calendar becomes one direct message to that person. When all seven have an answer, you announce the date. If one fails, you change the date or the plan while it's still only your idea.
Check 1
The release owner, and a backup with a name
Someone runs the release: merges the last changes, cuts the build, watches the rollout and decides whether to roll back. If that person is out on the day, the release still happens, but every decision becomes a group chat. The backup matters just as much, because the owner can get sick the morning of.
Ask: "Are you here on the release day and the working day before it? If you're not, who takes it, and have they done it before?" A backup who has never cut a release isn't a backup yet. Pair them on the next smaller release first.
If they're out: name the backup now and give them the runbook this week, not the night before. If neither the owner nor the backup is around, move the date. That's the only check where I don't look for a workaround.
Check 2
QA and sign-off for the days before the date
People check whether QA is in on release day. The work happens earlier. Regression testing, the bug bash and the final sign-off usually land in the two or three working days before, and that's where an absence hurts. A tester who's out Monday on a Tuesday release has already cost you the release.
Ask: "Which days do you need for the regression pass, and are you here for all of them?" Ask the same of whoever else signs off: the product manager who accepts the feature, the designer who checks the final build.
If they're out: move the testing earlier rather than the date later. Freeze a day sooner, test while they're here, and agree who signs off if a fix lands after they leave. If you're planning that sprint around several absences at once, the same math applies as in planning a sprint when three people are away.
Check 3
On-call for the first 72 hours after the release
Most of the trouble from a release shows up after it, not during. The first 48 to 72 hours are when real traffic finds the edge cases, so the on-call schedule for those days matters more than the one for release day itself.
Ask: "Who's on call from release day through the third day after? Do they know this release is in their window, and do they know the systems it touches?" A Tuesday release keeps those 72 hours inside the work week. A Thursday release puts them on the weekend.
If they're out, or it's someone new: swap the rotation for that week, or add a second person as named backup for the window. Say you slip a release from Tuesday, November 17 to Tuesday, November 24, 2026. The 72 hours now run into Thanksgiving on Thursday the 26th and the Friday after, when half the team is traveling. That's a reason to move it to December 1 or back to the 17th, not to hope.
Check 4
The support lead and coverage for the ticket spike
A visible release brings questions: a changed screen, a moved button, a new email that customers didn't expect. Support takes the first wave, and they need someone who knows what changed and who to escalate to.
Ask the support lead: "Are you here the day of and the two days after? Who's covering the queue, and do they have the release notes and a contact on the engineering side?" Then make sure that engineering contact is actually in for those days.
If they're out: get the release notes and a short list of expected questions to whoever is covering, a few days early. If support is thin that whole week, ship the change behind a flag and turn it on when the lead is back.
Check 5
The author of the riskiest change
Every release has one change that worries you: the migration, the payments rework, the service only one person really knows. If that person is away when it goes out, a problem in it waits until they're back, or someone else learns the code under pressure.
Ask: "Which change in this release would you least like to debug without its author?" Ask the team, not only yourself. Then check that the author is in on release day and the two days after.
If they're out: either the risky change waits for the next release, or the author spends a session walking a second engineer through it before they leave, with a rollback plan written down. A change that can't be explained in an hour usually shouldn't ship without its author.
Check 6
Outside approvers and dependencies
Some of the people your release date depends on don't work for you. App store review takes as long as it takes, and someone on your side has to answer a rejection. A large customer may have its own change window and refuse changes outside it. Legal may need to approve new terms, and marketing may have an announcement, a blog post or an email scheduled to the hour.
Ask each one: "What do you need from us, by when, and who's your contact that week?" For app store builds, ask who on your team is watching the review and is in to resubmit.
If they're out or the window doesn't fit: submit earlier, decouple the announcement from the deploy, or ship to everyone except the customer whose window is closed. These dependencies are the reason I check outside people before anyone inside hears the date.
Check 7
Public holidays where people live, and team periods
Public holidays are the check everyone forgets, because they're not PTO and nobody asks for them. Picture a team with a QA engineer in Mexico City and a release on Tuesday, November 17, 2026. Monday the 16th is Revolution Day in Mexico, a public holiday, and it's the exact day you planned the final regression pass.
Ask: "Where does each person in this release live, and is there a public holiday there anywhere in the window?" Then look at the team's own periods: a code freeze that starts too late, an offsite that takes everyone out for two days, a company holiday, a release week another team already booked.
If one lands in the window: treat it like PTO for that person and go back to the check it affects. Holidays cluster at the end of the year, so if your release is in December, read planning December releases around holiday leave before you pick the date. The US holidays page and the holiday calendar have the dates.
Five habits that keep release dates honest
Put a backup name next to every role
Release owner, sign-off, on-call, support, risky change. If a role has one name and no backup, that's the check most likely to fail on the day.
Ask about plans, not only booked time off
"Anything planned that week, even tentative?" catches the trip that isn't booked yet. The tentative ones are the ones that turn into surprises.
Re-run the checks when the date moves
A date that slips a week is a new date. The on-call rotation, the holidays and the support schedule all changed with it.
Prefer a Tuesday or Wednesday
A release early in the week puts the first 72 hours on working days, with everyone around. A Friday release hands them to whoever is on call over the weekend.
Keep a one-line roster in the release ticket
"Owner: Ana, backup: Ben. Sign-off: Chloe. On-call: David. Support: Emma." When something breaks at 4:00 PM on day two, nobody has to ask who to call.
A checklist only works when someone runs it.Here's where it slips.
You can run every check above with the tools you already have: a calendar, the on-call schedule, a few direct messages. That's how most teams do it. These are the three places it breaks, usually a week after you checked.
The answers live in five places
PTO is in the HR tool, on-call is in the paging schedule, holidays are in each person's head, the code freeze is in a planning doc and the release date is in a Slack thread. Each check is easy. Putting them together is the work.
A check is a snapshot
Everyone is in when you ask. Two weeks later, someone books a long weekend that touches the release window and puts it on their own calendar. Nothing re-runs the check, so you find out in standup the week of.
A calendar shows who's out, not what they do
Seeing that Chloe is out Monday doesn't tell you she's the only person who signs off on the release. The roles and the absences need to be on the same view, around the date.
Run the checks once. Keep the release date on the timeline.
Put the release date on one timeline with everyone's time off, on-call and holidays, and Forgot names anyone who's away that day. Mark the days around it as a release week, and it names who's out during those too.
- Release dates as milestones, with a warning by name when someone is away
- Release week and code freeze periods that show who's away during them
- Public holidays for each person's own country
- A Role property (QA, Release owner, On-call, Support) to group the board by
Sign in with Google, no card. After the trial it's a one-time payment, not a subscription.
Questions
Who needs to be available on release day?
At minimum the release owner or their backup, someone who can roll back, and the on-call engineer. The people who sign off need to be around in the days before, and on-call, support and the author of the riskiest change need to be around for the two or three days after.
How do you plan a release around PTO?
Pick a candidate date, then check the release owner, sign-off, on-call, support and the riskiest change's author against it, including the days before and after. Fix anything that fails by naming a backup, moving work earlier or moving the date, and only then announce it.
How long should on-call cover a release?
Plan for the first 48 to 72 hours, because that's when real traffic finds the problems testing missed. Make sure the person on call in that window knows the release is in it and knows the systems it touches, and name a backup.
Should you release software before a holiday?
Avoid it when the days after the release include a holiday or a long weekend, since that's when on-call and the people who know the change are hardest to reach. If you have to, ship behind a flag and turn it on when the team is back.
What should be on a release checklist?
The technical items you already know (tests, migrations, rollback plan, release notes) plus availability: who owns the release and their backup, who signs off, who's on call for the following 72 hours, who covers support, and which outside approvals and holidays fall in the window.