Change proposals
How savings become reviewable changes, who can act on them, and how they stay current.
On this page
Generation
- Proposals are generated daily from the current savings, or on demand.
- Every change worth $25 or more a month gets its own proposal, up to 250.
- Smaller items are bundled per cluster, or per account and region for volumes, with a per-item evidence list and a $5 a month floor.
- Coverage reports how much of the savings total has a proposal.
Contents
Each proposal has a title, scope, current and proposed state, evidence, risk level, monthly saving, the patch or command as text, risks and safe rollout steps. An optional summary is written from the evidence only; it may raise the risk level, never lower it.
Review states
| Action | From | To |
|---|---|---|
| Approve | Proposed | Approved |
| Reject | Proposed, Approved | Rejected |
| Mark applied | Proposed, Approved | Applied |
| Reopen | Rejected, Approved, Superseded | Proposed |
Admins, platform engineers and team leads can act on proposals. Each action is written to the audit log with the reviewer and note. Reviewed proposals keep their decision when proposals regenerate; ones the data no longer supports become Superseded.
Approving a proposal opens a pull request on your repository through the KubeOn GitHub App. Your CI runs, a person merges it and your CD deploys it; KubeOn marks the proposal applied once the deployment is confirmed. See automation controls.
Need help with this guide?Contact support