Maintenance Windows
Changes a host’s monthly OS-patching window. You can skip it — the server is not patched or rebooted that month, and the reminder emails for that window are suppressed, with patching resuming on its own at the next window — or move it, keeping that month’s patching but on another date in the same month, at another time of day, or both, with the reminder emails following it.
Primary use: A month where a reboot would land badly — quarter-end close, a launch freeze, an incident in flight. Move it if the month’s patching still needs to happen; skip it if it doesn’t. If only the hour is the problem, change the time and keep the day.
Moving also runs the other way round: a window that has already passed can be given a date later in the same month, which schedules a run in addition to the one that went. That is how you get a FileMaker upgrade or a late OS update onto a host in a month whose window has been and gone — see Getting a second run in the same month.
This replaces asking the DevOps team to skip or move a window by hand. Changes take effect immediately and are recorded with who filed them and why.
Available for web application servers as well as FileMaker ones — the patching automation is the same either way, so skipping or moving a window works identically.
What gets suppressed
Each patched host has four schedules in AWX per cycle: the patching run itself, and the next-day, one-hour, and (on FileMaker hosts) fifteen-minute reminder emails. Skipping a window suppresses all four together, so nobody is told about maintenance that will not happen — including the day-before email, which goes out on the previous business day (the Friday before, for a window on a Monday).
Only the window you pick is affected. Every other month runs as normal.
Mac hosts can be skipped too. Not all of them are patched by AWX, though — pick one that isn’t and the wizard says so and files the rest of your selection without it.
Skipping a window
- Tools → Maintenance Windows, then Skip or move a window.
- Pick your client.
- Pick one or more hosts. Selecting every host in the client skips the whole app group; selecting one skips just that server.
- Tick the maintenance windows to skip. The next six are offered, with the imminent one marked next; a window already being skipped is shown as such and its tick can’t be removed, though you can still give it a date or time (see Changing your mind below). A window already being moved can’t be double-booked.
- Leave Patch on instead empty to skip the month entirely, or fill in a date, a time, or both to move the window — see below.
- Give a reason. It’s recorded with the request and shown to the DevOps team.
- Optionally add extra email addresses under Who gets told, comma-separated, for anyone outside the client who should know.
- Review and confirm.
Moving a window instead
Next to a ticked window are Patch on instead and at — a date and a time. Between them they cover the three things you might want:
| Date | Time | What happens |
|---|---|---|
| empty | empty | The window is skipped; no patching that month. |
| filled | empty | Patched on the new date, at the host’s usual time. |
| empty | filled | Patched on its own date, at the new time. |
| filled | filled | Patched on the new date, at the new time. |
Either way the whole run is the same — patches, backup check and reboot included. The current time is shown under the fields, so you can see what you’re changing from; leaving the time set to the host’s usual one counts as no change at all.
The new date has to be in the same calendar month as the window it replaces. That keeps it clearly a move of one month’s patching rather than a reschedule into a month that has its own window coming, and means no month is ever left without a window on the books.
Today counts as a date, so long as the time you pick is still ahead — the hours left in the day are usable. A window at 11pm tonight can be pulled forward to 6pm or pushed back to 11:30pm, and next Friday’s window can be brought forward to this evening. A time that has already gone is refused: AWX accepts a run dated in the past and then never fires it, so the window would go unpatched with nothing to show for it.
A window whose own run has already gone — today’s 5am window, looked at over morning coffee — can still be given a new date or time. What you file then is a run in addition to the one that went, which is a use of its own; it has its own section below.
The reminder emails follow the new date and time: the day-before, one-hour and (on FileMaker hosts) fifteen-minute warnings all go out for the day you picked and quote the time it will run at. The two same-day warnings keep their distance from the window, so a window moved to 9pm warns customers at 8pm and 8:45pm; the day-before email keeps its usual 10am slot. Nothing has to be corrected afterwards.
Moving a window to within a day or two means the day-before reminder can no longer go out — it would have needed to send on a day that has passed. The review step tells you when that’s the case. The move still happens; the customer just hasn’t been warned by email, so tell them yourself if they need to know. Changing only the time has the same catch in reverse: if the day-before email has already gone out, the customer has been told the old time and cannot be sent a correction.
A weekend date is allowed, and is often exactly what’s wanted. Bear in mind the patch run is unattended, so nobody is on call if it fails, and its day-before reminder still goes out on the preceding weekday.
Weekends aside, the portal doesn’t know about public holidays — it steps over Saturdays and Sundays only, the same as the reminders generated for every other window do.
Getting a second run in the same month
A window whose own run has already gone can still be given a date later in the same month. Doing that files a run in addition to the one that went, rather than relocating it — so the host is patched twice that month. That is the supported way to get a run onto a server in a month whose window has already passed, without waiting for next month or asking the DevOps team for a one-off.
Primary use: what the host installs has changed since its window ran. The monthly run is OS Updates, Install FileMaker & Base Deployment — it installs whatever OS patches and FileMaker version the host’s configuration calls for at the moment it runs — so once a new FileMaker version is in place for that host, another run is what actually puts it on the server. The same shape covers an OS update released just after the window went, and the original case this was built for: “the 5am run failed, put it on tonight instead.”
Only the team filing it knows whether the run that went did its job, so the portal states what it knows and leaves the call to you. The review step carries the warning in as many words — “…has already gone, so this schedules patching in addition to it rather than instead of it”. After a run that failed, that means the month gets patched once. After a run that worked, it means twice — which for an upgrade is usually the point.
Filing one
- Tools → Maintenance Windows, then Skip or move a window. Pick your client and the host or hosts.
- This month’s window is listed even though it has passed, badged this month — run already gone. Tick it. It is offered only for the month you are in: a window from a month that has closed has nowhere left to land, so it isn’t shown.
- Fill in Patch on instead with the date you want the run on, and at with a time if the host’s usual hour doesn’t suit — a time on its own puts the extra run later the same day.
- Give a reason. “FileMaker 2024 upgrade, August window already ran” is the kind of thing the DevOps team wants to read here.
- Review and confirm.
The date rules are the ordinary move rules: the same calendar month as the window, from today onwards, and before the host’s next window. Today counts so long as the hour you pick is still ahead of the clock. Reminder emails follow the new date and time exactly as they do for any other move, and everyone on the notify list is told the window moved.
A passed window that a skip held down is the one case where a late date is not an extra run: nothing was patched that month, so the date you file is the month’s only run and the portal leaves out the “in addition to it” warning. Filing a date on a skipped window is how you change your mind after the fact — “we skipped August, but we do want the upgrade out before September.”
Leaving both fields empty on a passed window is refused rather than filed. There is no longer a run for a skip to suppress, so an empty filing would do nothing while reading, on the list page, as a month skipped. The wizard says so and asks for a date or an untick.
If the month has run out — the window fell on the 29th and it is now the 31st — there is nowhere inside it left to land. The wizard doesn’t offer the fields and says as much; a one-off run from the DevOps team is then the only way to get one before next month.
Three or more runs in a month
Once the extra run’s own date has passed, the same window is offered again on the same terms, so a third run is possible while the month still has days left in it. Two upgrades plus the month’s regular patching all inside one month is a legitimate filing, not a loophole.
Each of those filings reuses the one record the portal keeps for that window, so the Maintenance Windows page shows only the most recent replacement date — the earlier extra run leaves no row of its own behind, and the reason field carries only the latest text. If you need a per-run record of a month with several runs in it, take it from AWX rather than from the portal’s list.
Cancelling an extra run leaves the month with nothing on the books after the original run — cancelling cannot put patching back on a date that has passed. If withdrawing the extra run is all you want, that is what happens; just be aware there is no normal date left to fall back to.
Changing your mind about a skip
A skip already in force can be turned into a move without cancelling it first. Start the wizard again for the same host: the window is ticked and greyed out, as it always was, but Patch on instead and at are there next to it. Fill in a date, a time, or both, and confirm — the skip becomes a move on the same record, and everyone is emailed that the window has moved rather than been skipped.
Leaving both fields empty leaves that skip exactly as it is, so a filing aimed at one window never disturbs another one already in force on the same host. Give the whole request a reason as usual; the amended window takes the new one.
A window already being moved works the other way round — its fields are not offered, because a replacement date is on the books and reminders have been generated for it. Cancel it and file again to change where it lands.
Who gets told
Everyone with access to the hosts you skipped is emailed — the whole client team, not just you. An unpatched window is a fact about a shared server, and the person who needs to know is often not the person who filed it. The DevOps team is copied, and so is anyone you added under Who gets told.
Both the window-picking step and the review step list the addresses that will be emailed, each tagged with why it’s on the list — you, has access, added by you, or DevOps — so you can see who’s covered and add anyone missing. Addresses you add appear in the list on the next step; the count in the card header is the total.
The same people are emailed again if the skip is cancelled, including your extra addresses — so nobody is left believing a window is skipped when it isn’t.
This is who hears that you changed a window, and it is not the same list as who hears about the window itself. The day-before, one-hour and fifteen-minute reminders go to the server’s Maintenance Contacts — the customer and the project team — which you can also edit. Changing a window does not change who its reminders reach, and vice versa.
The day-before reminder goes out on the previous business day. Skip a window after that has already gone out and the customer has had it — the window is still skipped, but they may need telling that it is.
Skipping two or more windows in a row means the server goes that many months without OS security patches. The review step warns you, but does not stop you — it’s your call, and it is recorded.
Cancelling
Anyone who can see the host can cancel a skip or a move, not just whoever filed it — so a teammate being away never leaves one stuck in place. Cancel from the Maintenance Windows page; the host then patches as normal at that window.
Cancelling after the window has already passed only tidies the record. A window that has gone cannot be re-run by cancelling its skip, so the host waits for its next one — or file a date on it to have the month patched later, as under Getting a second run in the same month.
Cancelling a move after its original date has passed but before the new date means the server is not patched at all that month — the original window has gone, and cancelling removes the replacement. The page tells you when that’s what happened. A time change has no such gap: both dates are the same day, so cancelling one simply puts the window back at its usual hour.
Checking what’s in force
The Maintenance Windows page lists every skip and move on hosts you can see, plus the last six months of past and cancelled ones. A window listed under Past & cancelled as skipped was not patched that month; one shown as moved was patched on the second date instead, and one shown as re-timed on its own date at the time given.
A skip briefly showing not yet applied in AWX means AWX hasn’t confirmed it yet. This resolves by itself; if it persists and the window is close, contact the DevOps team.
A row filed against a window whose own run has already gone — “the 5am run failed, put it on tonight” — never shows that warning, because there is nothing left for it to suppress: what the portal confirms in that case is the replacement run it filed, not a schedule it held down. Its re-timed or moved badge is the whole of the state.
For the same information laid out as a calendar — and to subscribe to it from Calendar on your Mac, so skips and moves reach you without checking the portal — see Maintenance Calendar.