Execution safety
Guardrails that apply before anything changes
Permanently blocked actions, a production block that’s on by default, per-account policy and single-use overrides, checked before every change at every autonomy level.
Its spend ceiling doesn’t cap what your cloud costs.
The problem
Automation is only worth turning on if you can bound it. One script that stops the wrong instance in the wrong account costs more than the waste it was meant to remove.
How it works
Resolve
The policy for the target account is worked out in layers: the built-in default, deployment settings, your workspace rule, then the account’s own setting.
Check
Before any change, the action is checked against the blocked list, the production rule and, if you saved them, your kill switch and limits. A failed check stops the run.
Notify and override
If notifications are on for that account, a block by the blocked-action list or the production rule goes to the in-app bell, to Slack where it’s connected, and by email to the addresses saved in Settings → Notifications. For a production block, an owner or admin can then run that one change once.
Blocked
in code: terminating or deleting an instance, and deleting a database or bucket
By default
accounts labelled production are blocked
Single-use
override that lifts only the production block, for one approved change
Opt-in
kill switch, cool-down, execution cap: none apply until a configuration is saved
Capabilities
Safety rules every change passes before it runs in AWS, whoever approved it.
Some actions are never allowed
Terminating or deleting an instance, and deleting a database or bucket, are blocked outright. No policy, override or autonomy level unblocks them, and an action outside the supported list is refused before any AWS call.
Production is a property of the account
Accounts labelled production are blocked by default. An account with no label counts as production too, so it’s protected until you label it. Set the rule for the whole workspace, then change it per cloud account, so fixes can run on staging while production stays protected.
Single-use overrides
When a block is wrong, an owner or admin can run that one approved change once, from the app or Slack, on a paid plan or active trial. The override lifts only the production block and is recorded with its account.
Kill switch and daily limits
Save a guardrail configuration to add a workspace kill switch, a cool-down between executions and a cap on executions per 24 hours. Until one is saved, these three limits don’t apply.
In depth
What is blocked, and what needs a person
Every change goes through the same plan stage, whether it was approved in the app, in Slack or through the API, or its action type is set to run without a person. That stage refuses any action outside the supported list before an AWS call is made, then applies these rules:
- Terminating or deleting an instance, and deleting a database or bucket, are always blocked. They aren’t part of the policy you can edit.
- Deleting an EBS volume or snapshot is destructive, so a run nobody approved is refused.
- A run in an account that counts as production is blocked unless your policy allows it.
Policy per workspace and per account
The production rule is resolved in layers: the built-in default, then deployment settings, then your workspace rule, then a setting for the specific cloud account. Anything an account leaves unset is inherited, and Settings → Automation Safety shows which layer each value came from.
So you can block production across the workspace and still allow fixes on a staging account. You can also change which environment names count as production; the default list is production, prod and prd.
Whether a run counts as production comes from the account’s environment label, looked up on the server for each run, wherever the change was approved. An account with no label, or one that can’t be looked up, counts as production. The label can raise a run to production but can’t lower one.
Notifications and overrides
Block notifications are off by default. Turn them on for the workspace or an account, and a block by the blocked-action list or the production rule goes to the in-app bell, to that account’s Slack channel or your approvals channel if Slack is connected, and by email to the addresses saved in Settings → Notifications. Each one names the action, resource and reason, and the account when the run has one.
To run a change the production rule blocked, an owner or admin can use “Override & run once” on the Slack card or in Settings → Automation Safety, which lists recent blocks.
An override lifts only the production block, for one change that was already approved. Blocked actions and your other limits still apply. The override is recorded with its account, and if that action type was set to run on its own, it goes back to “approve each”.
Kill switch, cool-down and execution cap
These limits are opt-in. Once an owner or admin saves a guardrail configuration, every execution in the workspace is checked against it. Each execution records the limits and counts that applied.
- Kill switch: stops every execution in the workspace until it’s turned off. Each execution reads the saved settings when it is checked.
- Cool-down: a minimum number of hours since the workspace’s last running or successful execution.
- Execution cap: a maximum number of running or successful executions in the last 24 hours.
What the audit trail records
When a change runs, an audit event records the action, the resource, the state before and after, whether the post-check passed and whether the change was rolled back. Overrides, policy changes and autonomy changes are logged too, and a blocked run keeps its reason in the execution’s stage log.
You can read the trail on the Audit Log page, or query it by event type, action, execution, resource, actor or date through the API. Each record gets a SHA-256 checksum when it’s written, so a later edit to its core fields can be detected.
What it does not do
- Its spend ceiling doesn’t cap what your cloud costs. Once a guardrail configuration is saved, it refuses a change when that change’s estimated monthly saving, added to those of the changes that succeeded in the last 24 hours, is above the ceiling.
- It doesn’t apply the kill switch, cool-down or execution cap until a guardrail configuration is saved.
- It doesn’t work out which accounts are production from what runs in them. You label each account, and until you do it counts as production.
- It doesn’t sign the audit trail. The checksum uses no secret key, so it’s tamper-evident rather than proof of who wrote a record, and it doesn’t cover the before and after state.
- It doesn’t send block notifications unless you turn them on.
- It doesn’t send a notification when the kill switch, cool-down or execution cap stops a run.
FAQ
Questions
Can automation delete resources?
It can delete EBS volumes and snapshots, which findings propose for unattached volumes and old snapshots, but only with a person’s approval: a run nobody approved is refused for any destructive action. Terminating or deleting instances, and deleting databases or buckets, are blocked outright.
How do we stop everything in an emergency?
Turn on the kill switch in your guardrail settings. Once a guardrail configuration is saved, the kill switch stops every execution in your workspace until you turn it off.
How does GetFinOps know an account is production?
From the account’s environment label: production, staging, development or test. You choose it when you add the account and can change it in Settings → Accounts. An account with no label, or one GetFinOps can’t look up when the change runs, counts as production, so the production block applies to it.
Who hears about a block?
Nobody, until you turn on block notifications for the workspace or an account; they’re off by default. Then a block by the blocked-action list or the production rule goes to the in-app bell, to the account’s Slack channel or your approvals channel if Slack is connected, and by email to the addresses saved in Settings → Notifications. A run stopped by the kill switch, cool-down or execution cap sends no notification.
Try free — no credit card
Create a workspace and connect an AWS or GCP account, or book a demo first.