Auto-Remediation: From Recommendation to Cloud Change
A recommendation is only useful once something changes. This is how the Remediate button makes that change, and when it refuses to.
What happens when you press Remediate
Every recommendation that has a wired lever carries a Remediate button. It opens a wizard that runs the fix as a short workflow rather than a single API call:
- Precondition. ZopNight re-checks that the resource is still in the state the recommendation described.
- Approval (when needed). Destructive operations pause for an admin. A non-admin can start the workflow, and an admin approves or rejects the step. The approval request goes out through your notification channels.
- The cloud action. Depending on the rule this is a start or stop, a pause, a resize (with or without a stop), a delete, a storage lifecycle policy, or a patch to a live Kubernetes manifest.
- Validate. The workflow confirms the resource reached the intended state before it reports success.
Some fixes run as auto (one click, gated by admin approval for non-admins). Others are guided, which adds a type-to-confirm review so a human reads the change before it lands.
Why some levers are held back
A central safety gate looks at the actual resource, not just the rule. Its choices are deliberate:
- A one-shot stop on a VM is never automatic. No cloud API reveals what runs inside a generic instance, so a stop could be an outage. Those findings become advisory, and the right lever is a recurring schedule.
- A delete needs proof. ZopNight only offers an automatic delete when the control plane says the resource is unused: a public IP with no association, a disk detached for at least seven days, a snapshot whose source is gone, or an empty backup vault. Without that evidence the finding stays advisory.
- Stateful resources are not auto-rebooted. A resize that needs a stop is demoted when the target is a managed database.
- Customer databases are never paused or mutated by the pause template.
Two examples of guided-only handling: a single-replica Kubernetes Deployment is scaled from one to two replicas only after review, and Azure Hybrid Benefit is applied as a reversible licensing setting.
When there is no button
Advisory rules show a numbered “How to Fix” playbook in the drawer instead. Schedule-class findings, such as dev and test compute running around the clock, open schedule creation with the resource prefilled, because their saving comes from a recurring window and not a one-time stop.
Remediation needs a cloud account connected with read + write access. Read-only accounts still get every recommendation.
If a step fails, the error is sorted into a permission or quota problem (with a fix hint), a transient cloud error (with a retry), or an unsupported operation. Before you approve anything, pre-flight impact analysis shows which connected resources the change touches. For the cleanup side see orphan resource cleanup, and for the concept, auto-remediation explained.
Questions we get a lot.
Can a non-admin delete a resource through remediation?
They can start the workflow, but destructive steps wait for an admin to approve them before the cloud action runs.
Will ZopNight stop a production VM on its own?
No. One-shot stops on compute are demoted to advisory by the safety gate. The supported way to cut idle VM hours is a recurring schedule you define.
What access does remediation need?
The cloud account must be connected with read + write permission. Read-only accounts get discovery and recommendations, and ZopNight blocks any change before a cloud call is made.