What happens when a patch breaks a host?

The run stops for that host, restores it from the snapshot taken before patching, and opens a ticket with the logs. The rest of the wave continues only if health checks pass.

Does it replace Systems Manager or Ansible?

No. Agents drive the tools you already use, such as Systems Manager, Ansible and Terraform. They add planning, checks, rollback and the record around them.

Who decides when work runs?

You do. Maintenance windows, wave sizes, blackout dates and what needs approval are written in the policy before anything runs.

Can it work outside AWS?

Yes. The same routines run on Azure, GCP and on-premises hosts connected to CloudThinker, under the same policy and audit trail.

AWS Partner

SOC 2 Reports

Frontier Resolutionfor Day-2 Operations

Patching, certificate and secret rotation, scaling and storage done on schedule.

Patching, certificate and secret rotation, storage expansion and scaling are the work that keeps production up and never makes the roadmap. Agents run it on the schedule and policy you set, check each change before and after, and hand your team a record of what ran and why.

Book a Demo See how it works

Maintenance windowcompleted

Monthly patching: 212 instances, 3 accounts

Scope: Patch baseline prod-linux, 212 instances in 3 accounts
Pre-check: Snapshots taken, 2 hosts skipped: active batch jobs
Rollout: 4 waves of 25%, health checks between waves
Exception: ip-10-2-14-8 failed to reboot. Restored from snapshot
Result: 209 patched and healthy. 3 rescheduled for Sunday

Compliance report sent to #ops-maintenance

[The work behind every maintenance window]

Certificates expire on a date.Someone still has to remember it.

01The manual work

Maintain

Engineers track expiry dates in spreadsheets, patch in late-night windows and grow disks after the alert, not before.

02The agent handoff

Done on time

Frontier agents plan each task, check the system before and after, run it in safe waves and roll back if health checks fail.

03Your engineers’ role

Approve

Set the schedule, the blast radius and what needs a person. Review the exceptions, not the routine.

[Where CloudThinker fits]

Your stack stays.Agents work inside it.

01Fleet

Wherever your hosts run

AWS Systems ManagerEC2 inventory, patch baselines
Azure Update ManagerVM patching and compliance
Google Cloud VM ManagerOS patch jobs and inventory
Linux and Windows hostsOn-prem servers and VMs
HashiCorp VaultSecrets and leases

No change to your tooling

02Runbooks and change

Your system of record

AnsiblePlaybooks you already trust
TerraformInfrastructure as code
ServiceNowChange requests and windows
Jira Service ManagementOps tickets and approvals

Change process stays put

03Routine work

CloudThinker

Patch in wavesCanary hosts first, then the fleet
Rotate on timeCertificates and secrets before expiry
Expand and scaleDisks and capacity before they fill
Roll backRestore a failed host from snapshot

Runs inside your change window

04Response

Done, then reported

SlackRun summary in the ops channel
Microsoft TeamsUpdates for the wider team
JiraExceptions with owners
DatadogHealth checked after each wave

Each wave runs on approval

Logos show common stacks. CloudThinker connects to each one through scoped access you approve.

[Example scenario]

Sunday, 01:00. Patch night.Nobody on the team is awake for it.

A 12-person ops team running 212 EC2 instances across 3 AWS accounts, plus 40 TLS certificates and 90 service secrets. A critical OpenSSL patch landed on Thursday.

00:45
Pre-checks runAgent
Confirms the patch baseline, takes EBS snapshots and skips 2 hosts running finance batch jobs until they finish.
01:00
Wave 1 of 4Agent
Patches 25% of instances through Systems Manager, reboots, then waits for load balancer health checks to pass.
01:38
One host failsSignal
ip-10-2-14-8 does not come back after reboot. Health check fails for 5 minutes.
01:40
Rolled back, rollout continuesAgent
Restores the host from its snapshot, pulls it from the wave, opens OPS-774 with the console log, and continues with the healthy hosts.
03:10
Rotation and capacityAgent
Renews 3 certificates due in 14 days, rotates 6 database secrets with zero failed logins, and grows a log volume at 81% full.
08:30
Team reviews one exceptionYour team
The on-call engineer reads the morning summary, checks OPS-774 and approves a rebuild of the failed host.

#ops-maintenance4 messages

CloudThinker00:45
Starting monthly patching: 212 instances in 4 waves. Snapshots done. Skipping 2 hosts with active batch jobs until 02:30.
CloudThinker01:40
ip-10-2-14-8 failed to boot after patching. Restored from snapshot and removed from this run. Opened OPS-774 with the console log. Other waves continuing.
CloudThinker03:40
Done. 209 patched and healthy, 3 rescheduled. Renewed 3 certificates, rotated 6 secrets, expanded logs-vol-02 to 500 GB. Compliance report attached.
On-call engineer08:30
Read the log on OPS-774. Approved the rebuild.

instances patched with no one awake: 209
exception for the team to review: 1
expired certificates or failed logins: 0

An illustrative example. Team, systems and times are representative, not a specific customer.

[Frontier resolution agents]

Routine work runs on time.Exceptions reach a person.

Agents run day-2 work on the same policy every time, so maintenance stops depending on who remembers what, and every change leaves a record your auditors can read.

Patch in safe waves: Snapshots first, then rolling waves with health checks between each one. A failed host is restored, not left broken.
Rotate before expiry: Certificates and secrets renewed ahead of their dates, with each consuming service checked after the change.
Grow capacity early: Disks, volumes and node groups expanded when the trend says so, not when the alert fires.
Keep the record: Every run produces a report: what changed, what was skipped and why, and what still needs a person.

[What changes]

Same team. Same tools.Far less of the work by hand.

Moment	Today	With frontier agents
Patch night	Engineers awake until 4am	Runs in waves, reviewed over coffee
Certificate expiry	Found when the site breaks	Renewed weeks ahead, checked after
Secret rotation	Skipped because it might break things	Rotated on schedule with each service verified
Disk space	Expanded after the 95% alert	Grown early from the usage trend
Audit evidence	Screenshots collected by hand	A report from every run

[Integrations]

Connects to the rest of your stack.Read-only to start.

AWS Systems Manager
AWS Certificate Manager
AWS Secrets Manager
Amazon EC2
Amazon EBS
Amazon CloudWatch
HashiCorp Vault
Ansible
Terraform
ServiceNow
Jira Service Management
PagerDuty
Datadog
Slack
GitHub

[Adoption path]

One pilot.Then company-wide.

The rollout follows the four phases of the AWS Cloud Adoption Framework, so it fits the plan your cloud team already runs.

01Envision
Start with one runbook
Pick the task your team dreads most, often patching or certificate renewal, and let agents plan it in dry-run mode.
02Align
Set windows and limits
Agree maintenance windows, wave sizes, health checks and which failures stop the run.
03Launch
Add the other routines
Secret rotation, storage, scaling and log rotation join on the same schedule and the same report.
04Scale
Make it the default
New accounts and services inherit the routines on day one. Your team only sees the exceptions.

[Customer proof]

F88.Results on the record.

A Vietnamese consumer-finance company with 800+ branches encoded its runbooks once and applied them across accounts and environments.

Read the case study

of daily operations automated: 80%
lower AWS spend: 30%

[AWS guidance]

Built the way AWS says to run it.Reviews start from a known reference.

[Trust and control]

Agents do the work.Your team keeps control.

You approve every change: Agents propose. Nothing touches production until someone on your team says yes, and you set that rule per system.
Every action on the record: Each step is logged, attributed and reversible, ready for your auditors.
Certified for enterprise: SOC 2 Type II and ISO 42001, with reports in our trust center.
Runs where you need it: In our cloud, through AWS Marketplace, or inside your own account.

[Questions]

What teams askbefore they start.

What happens when a patch breaks a host?: The run stops for that host, restores it from the snapshot taken before patching, and opens a ticket with the logs. The rest of the wave continues only if health checks pass.
Does it replace Systems Manager or Ansible?: No. Agents drive the tools you already use, such as Systems Manager, Ansible and Terraform. They add planning, checks, rollback and the record around them.
Who decides when work runs?: You do. Maintenance windows, wave sizes, blackout dates and what needs approval are written in the policy before anything runs.
Can it work outside AWS?: Yes. The same routines run on Azure, GCP and on-premises hosts connected to CloudThinker, under the same policy and audit trail.

[Go deeper]