Rolling patch and reboot
Trigger: Monthly maintenance window
- 1Drain the host from the load balancer or cluster
- 2Apply approved package updates
- 3Reboot and wait for services to report healthy
- 4Return the host to service and verify traffic
Server and Data Center Operations
Run Routine Operations the Same Way Every Time.
Patch cycles, firmware updates, capacity moves, decommissions and site checks are the work that never stops and rarely gets documented properly. StackHeal turns them into scheduled, staged workflows with approvals, progress visibility and a record of every run.
- Staged rollouts with health checks between batches
- Approvals and maintenance windows built in
- A written record of every operation performed
Maintenance run · AMS-1
Rolling, 2 at a time
rack A4 · hv-11
Donerack A4 · hv-12
Donerack A4 · hv-13
Runningrack A5 · hv-14
Queuedrack A5 · hv-15
Needs approval
Benefits
Operations work, made repeatable
Maintenance that runs in batches
Roll changes across a fleet in waves, with health verification between each wave and an automatic stop when a wave fails.
Recurring tasks that actually recur
Scheduled operations run on time whether or not anyone remembered, and report when they could not.
Fewer hand-written runbooks
A workflow is the runbook, and it is executable. The documentation and the procedure cannot drift apart.
Multi-site coordination
Sequence work across sites, racks and tenants with dependencies and holds, rather than coordinating in a spreadsheet.
How it works
How an operations run is structured
Every run has a plan, a gate, a sequence, and a result.
- 01
Define the operation
Compose the task from registered actions — package updates, firmware pushes, service drains, configuration changes, physical checklists.
- 02
Select the target set
Choose targets by inventory query, tag, rack, site or tenant, and preview exactly which assets the run will touch.
- 03
Schedule and gate
Bind the run to a maintenance window, require approval where policy demands it, and set the batch size and failure threshold.
- 04
Execute in waves
Each batch runs, then is health-checked before the next begins. A failed check pauses the run instead of propagating the problem.
- 05
Report
The run closes with a per-asset result, the output captured, and anything skipped or held clearly listed.
Example workflows
Example operations workflows
The recurring work that fills an operations calendar, expressed as workflows.
Firmware and driver campaign
Trigger: Vendor advisory or scheduled campaign
- 1Match affected models from inventory
- 2Require change approval for the campaign
- 3Stage updates rack by rack inside the window
- 4Verify version and hardware health after each host
Capacity rebalance
Trigger: Utilisation threshold on a cluster
- 1Identify candidate workloads to move
- 2Validate target capacity and placement rules
- 3Migrate with approval above a size threshold
- 4Confirm workload health after each migration
Site check and decommission
Trigger: Scheduled audit or asset end-of-life
- 1Generate the per-rack checklist for the technician
- 2Reconcile what was found against inventory
- 3Wipe and release assets after sign-off
- 4Update inventory, monitoring and billing records
About these examples
These describe workflow patterns the platform is designed to run, with the steps a team would configure. They are illustrations of the product model — not recordings of a specific customer deployment.
Compatibility
Integrations this product uses
Systems connect through maintained connectors or through their own APIs and webhooks. Check the directory for each system's current status.
Execution
- Ansible
- Shell and PowerShell over managed transport
- Vendor management APIs
- Redfish / IPMI
Platform and inventory
- Proxmox VE
- VMware vSphere
- DCIM and asset inventory
- IPAM and DNS
Coordination
- Change records in your service desk
- Maintenance notifications
- Chat updates
- Webhooks
Controls
Security and operational controls
Fleet-wide operations are exactly where a mistake scales. These limits are not optional extras.
Target preview and confirmation
Every run shows the resolved asset list before it starts. No run proceeds against an unreviewed target set.
Batch size and failure thresholds
Define how many assets per wave and how many failures stop the run. Defaults are conservative.
Change approvals
Tie runs to your change process, with approval required per campaign, site or environment.
Captured output
Command output and exit status are retained per asset, so you can answer what happened on a specific host months later.
Related products
StackHeal products share one workflow engine, one action catalogue and one run history.
Learn more about VM Provisioning
VM Provisioning
Standardize virtual machine provisioning and infrastructure lifecycle operations.
Learn moreLearn more about Infrastructure Monitoring
Infrastructure Monitoring
Connect monitoring signals with troubleshooting and approved remediation workflows.
Learn moreLearn more about Workflow Orchestration
Workflow Orchestration
Connect systems and automate repetitive operational processes.
Learn moreServer Operations questions
The questions we are asked most often in evaluation calls.
Something not covered here? Ask our team.
No. StackHeal schedules, gates, batches and records the work, and calls Ansible or your existing tooling to perform it. Your playbooks stay where they are.
They are reported as skipped with a reason and can be rolled into a follow-up run. They are never counted as successful.
Yes. Waves can proceed automatically after a successful health check, or pause for confirmation — configurable per operation.
Yes. A workflow step can be a human checklist assigned to a technician, with its completion recorded in the same run history as the automated steps.
Ready to try server operations against your own workflows?
We will scope a proof of concept around one or two of the request types your team handles most often, and show you what the run history looks like.