Detection without action is half the work. A finding for a public S3 bucket is useful only if someone fixes the bucket. A finding for an over-provisioned VM is useful only if someone resizes it. The gap between detection and fix is where most cloud governance programs lose value.
Auto-remediation closes that gap by running the fix on the user’s behalf. The hard part is doing it safely. A naive script that deletes every detached EBS volume looks great in demo and disastrous in production when the volume contained the only copy of the data nobody bothered to back up. The difference between responsible auto-remediation and a sharp tool pointed at the user’s foot is the safeguards.
ZopNight ships 20 audit rules certified for one-click auto-remediation as of 2026-05-07. Each runs through a four-stage wizard with explicit safeguards at every step. The list grows as new rules pass certification.
This guide keeps the theory short and spends most of its length on what you can actually do. Every recommendation here is one ZopNight can help you execute, starting from a read-only connection.
The four-stage wizard
Stage one is the precondition check. The engine confirms the resource is still in the state the rule expects, that no other recent activity has touched it, and that the operator has the right permissions. A precondition mismatch aborts the run. Stage two is the approval gate. Certified rules opted into auto-execute proceed automatically; everything else waits for an explicit human approval. Stage three is execution through the provider API. Stage four is post-execution validation: the engine confirms the resource ended up in the expected state and rolls back or surfaces the failure if it did not.
What is excluded by design
The remediation engine has a hard exclusion list covering rds*, aurora*, cloudsql*, elasticache*, postgres*, mysql*, and azure-sql resource types. Customer databases are explicitly outside the auto-remediation surface. Database changes always go through manual review and require explicit approval per resource. This is not a configuration the user can override; it is a platform-level guarantee.
Failure handling
Failures fall into three categories. user_action (yellow) means the operator must do something, reauthorize cloud credentials, fix a missing tag, install an agent. transient (blue) means a retry will likely succeed, often a rate limit or quota exhaustion. system (red) means a fix is required from the platform team, an unsupported resource state or a missing permission. The categorization matches how operators actually triage failures: did I do something wrong, will the next retry work, or is this a platform bug.
When to enable auto-remediation
Most teams start with approval-required mode for every rule and graduate selected categories to auto-execute as confidence grows. Idle resource cleanup and orphan resource removal usually graduate first because the actions are reversible or low-impact. Security rules that touch IAM or encryption follow once the team has confidence in the precondition and validation logic. Rules that affect production workloads almost always stay in approval-required mode permanently.
Key takeaways
- Auto-remediation closes the loop between detection and fix, but the safeguards matter as much as the action.
- A four-stage wizard (precondition, approval, execution, validation) is the practical pattern for safe auto-remediation.
- Customer database resources are excluded from auto-remediation by design, not by configuration.
- Three error categories (user_action, transient, system) give operators the right next step on every failure.
- Most teams start with approval-required and graduate selected rules to auto-execute as confidence grows.
Where ZopNight fits
ZopNight turns this from reading into doing. It ships 490 built-in audit rules across AWS (216), GCP (127), and Azure (147), 124 of those recommendations are wired to act end to end, 28 one-click and 96 guided, and it starts read-only so you can see the opportunity before you act on any of it. The most direct place to begin is scheduling non-production resources to your working hours, which is covered in the FinOps guide and shown concretely for AWS EC2.
How ZopNight schedules non-production resources
The loop that does this is deliberately mechanical, and it starts read-only. You connect your cloud provider with a read-only role, and ZopNight discovers every non-production resources across your regions and accounts. It records a per-action permission verdict for each one, so you can see where it can list a resource but not yet stop it, and you review that inventory, filter it by status or type, and search for the specific resources you care about before anything is scheduled.
Scheduling itself is a cron you write once in plain terms, stop at 7 PM, start at 8 AM on weekdays, pinned to your timezone so the jobs fire at local business hours rather than UTC. A weekly 24-hour grid shows the schedule visually so you catch gaps and overlaps before you save, and an estimate of active versus inactive hours appears before you commit. Resources attach individually or bundle into groups like “dev-cluster” or “staging-db” so a whole environment follows one cadence.
Actions run in dependency order, so a database comes up before the app server that depends on it. When something needs to stay up, an override forces a non-production resources ON or OFF for a defined window, carries a reason so teammates understand why it exists, and expires automatically so nothing is left running by accident. If a start or stop fails, ZopNight retries up to three times and falls back to a dead-letter queue rather than silently dropping the action, and every state change lands in an audit trail that records whether a schedule, an override, or a specific user triggered it.
Getting started
Getting started is intentionally low-stakes:
- Connect your cloud provider with a read-only role. Nothing is scheduled or changed at this stage.
- Let ZopNight discover your non-production resources and review exactly what it found, filtered by account, region, and status.
- Create a schedule in your timezone and attach the non-production resources or groups you want it to cover.
- Watch the first cycle run, with Slack, Teams, or Google Chat notifications on every start, stop, and failure, then layer in idle cleanup and guided rightsizing.
Production stays excluded by default throughout, and because discovery and recommendations are read-only, you can prove the value before you enable a single action.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
How many rules are certified for auto-remediation today?
ZopNight has 20 audit rules certified for one-click auto-remediation as of 2026-05-07. The list grows as new rules pass certification.
Can I add my own custom auto-remediation rules?
Custom auto-remediation requires the rule to be certifiable: precondition, approval gate, execution, and validation must all be implementable for the action. Open a feature request with the rule and remediation behavior.