Turn on auto-remediation for the 20 certified ZopNight rules. Configure scope, approval policy, and notifications. Customer database resources are excluded by design.
This is the practical version, the one you can follow in a single sitting. It starts read-only, touches no production resource by default, and every step is reversible, so there is no point at which you are committed to something you cannot undo. Budget about 15 minutes. Before you start you will want: Org admin role for the initial enable; At least one cloud account with active findings; A ZopNight account on a plan that includes remediation.
The steps
- Confirm your role and policy.
- Review the certified rule list.
- Set the scope.
- Configure the approval policy.
- Enable notifications.
- Run the first remediation.
Why this is safe to do today
The reason this is a low-stakes change is that nothing here is destructive. Scheduling stops and starts resources; it never deletes them, and your data persists across a stop exactly as it does across a normal reboot. Production is excluded by default, actions run in dependency order, and every state change is logged with what triggered it.
If you want the fuller context behind this task, the FinOps guide covers where it fits, and the AWS EC2 scheduling page shows the same loop applied to a specific resource.
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.
Will auto-remediation touch my databases?
No. The remediation engine has a hard exclusion list covering rds*, aurora*, cloudsql*, elasticache*, postgres*, mysql*, and azure-sql resource types. Database changes always go through manual review.
Can I undo a remediation?
Certified remediations are reversible or low-impact by design. The activity log records the resource state before and after. For attached-volume removal and similar actions, the cloud provider history retains the resource for a recovery window.
How do I add a custom rule to auto-remediation?
Custom auto-remediation requires the rule to pass certification (precondition, approval gate, execution, validation must all be implementable). Open a feature request with the rule and remediation behavior; the platform team certifies the rule and adds it to the list.