If you've been following my blog series, you know I've already set up AWX, synced GitLab projects, and run my first playbook. The next piece I wanted to explore was how AWX handles more complex automation tasks.
In this post, I'll cover two features I've started using more and more: Workflow Templates and Schedules.
Here's what I'll walk through:
- What Workflow Templates are and when they're useful
- How I built a patching workflow by chaining multiple job templates together
- How I configured a schedule to run a playbook automatically every Monday at 5 AM
Let's get started.
Workflow Templates
When I first started using AWX, I mostly worked with standard job templates. For simple tasks, they did exactly what I needed — run a playbook against an inventory and return the results.
As I started building more realistic automation tasks, I realised most jobs weren't a single playbook run. A typical maintenance task might involve patching servers, rebooting them, running validation checks, and then notifying the team once everything is complete.
I could run each of those steps manually, but it quickly became tedious and left plenty of room for mistakes.
That's where Workflow Templates came in. They allow you to link multiple job templates together and define what should happen when a step succeeds or fails. Instead of managing each stage yourself, AWX handles the flow for you.
For me, this was the point where AWX started feeling less like a tool for launching playbooks and more like a platform for automating operational processes.
My Real-World Use Case – Patching Workflow
I didn't fully appreciate Workflow Templates until I started building a server patching process.
Originally, I was launching individual job templates one after another: run pre-checks, patch the server, reboot it, verify services, and finally send a notification. It worked, but it meant I had to monitor every stage and decide manually what to do if something failed.
Moving that process into a Workflow Template made things much easier. AWX could handle the sequence automatically and stop the workflow if a critical step failed.
The workflow looked like this:
Stop Application → Pre-Patch Check → Patch Servers → Reboot → Post-Patch Check → Start Application
Each step is a separate playbook, chained together in AWX as a workflow. If any step fails, the workflow stops right there — the next step doesn't run. That's critical. You don't want servers rebooting if the pre-patch check failed.
Step 1 — Create the Individual Job Templates First
Before building the workflow, I made sure each playbook was already in GitLab and each had its own job template in AWX. Here's what I set up:
Each of these was already tested individually before I built the workflow. That's important — don't try to debug a workflow and individual playbooks at the same time.
Step 2 — Create the Workflow Template
AWX UI → Templates → Add → Add Workflow Template
Click Save
This opens the Workflow Visualiser — a drag and drop canvas where you build the flow visually. This is where it gets satisfying.
Step 3 — Build the Workflow in the Visualiser
In the Workflow Visualiser:
Click Start → a window pops up asking you to select a node
Select Stop Application job template → click Save
Hover over the Stop Application node → click the + button
Select On Success → select Pre-Patch Check → click Save
Repeat for each step — always connecting On Success to the next playbook
Here's the full chain I built:
Start
└── Stop Application
└── [On Success] Pre-Patch Check
└── [On Success] Patch Servers
└── [On Success] Reboot Servers
└── [On Success] Post-Patch Check
└── [On Success] Start Application
The key here is On Success at every step. If patching fails, AWX stops the workflow right there — servers don't reboot, application doesn't try to start on a broken system. That's exactly the safety net you need in production.
Click Save when the workflow is built
Step 4 — Launch the Workflow
Go to Templates → find Patching Workflow
Click Launch 🚀
AWX shows you the workflow running in real time — each node lights up green as it completes or red if it fails. You can click into any node to see the full playbook output for that step.
Watching a 6-step patching workflow run end to end without touching anything is one of those moments that makes all the setup worth it.
AWX Schedules — Automating Recurring Jobs
Now the second feature — Schedules. Once you have job templates set up, you can tell AWX to run them automatically at any time or frequency without anyone manually clicking Launch.
My use case was simple but important — I have a refresh.yml playbook that needs to run every Monday at 5AM. Before schedules I had to remember to run it manually. That's not automation — that's just a reminder. Schedules fixed that completely.
Setting Up the Monday 5AM Schedule
AWX UI → Templates → open the job template you want to schedule
Click the Schedules tab at the top
Click Add
Field Value
Name Weekly Data Refresh
Start Date Set today's date or next Monday
Start Time 05:00 AM
Time Zone Select your timezone
Repeat Frequency Week
Run On Monday
Click Save
That's it. AWX will now automatically run refresh.yml every Monday at 5AM without anyone touching anything. You can verify it's set up correctly by checking the Next Run field — it shows you exactly when the next execution is scheduled.
Managing Schedules
A few things I find useful when managing schedules in AWX:
*Enable/Disable without deleting *— there's a toggle on each schedule. If I don't want the refresh to run during a maintenance window, I just disable it and re-enable after. No need to delete and recreate.
Multiple schedules on one template — you can add more than one schedule to the same job template. For example I could run refresh.yml every Monday at 5AM AND every first day of the month at midnight if needed.
Check the Activity Stream — after a scheduled job runs, go to Activity Stream in AWX to confirm it ran and whether it succeeded or failed. This is your audit trail for scheduled jobs.
Errors I Hit Along the Way
Error 1 — Workflow Node Not Connecting
When building the workflow, I kept clicking the + button but the connection line wasn't appearing between nodes.
Fix — make sure you hover directly over the node until you see the + appear, then click it. If you click too fast it doesn't register. Slow down and wait for the hover state.
Error 2 — Wrong Timezone on Schedule
My schedule was set up but running at the wrong time. The job was triggering at 5AM UTC instead of my local time.
Fix — when creating the schedule, always explicitly set the Time Zone field to your local timezone. Don't assume it defaults to your local time — it defaults to UTC.
Error 3 — Workflow Skipping Failure Path
When a node failed, the workflow was completing instead of stopping.
Fix — I had accidentally connected some nodes with On Either instead of On Success. Go back into the Workflow Visualiser, click each connection line and check it says Run on Success. Change any that are set to On Either or Always.
What actually changed
Before workflows, patching was basically manual SSH work stitched together step by step. It worked, but it was fragile and very dependent on the person running it.
Now it’s just one workflow execution.
Same with schedules — anything recurring used to rely on memory or reminders. Now it just runs.
Nothing revolutionary individually, but together it changes how you approach automation. You start thinking in systems instead of tasks.
This is what proper production automation looks like — reliable, auditable, and hands-off.
Drop your questions in the comments — happy to help!
— Sireesha
Top comments (0)