Fix History
Immutable audit log of every change CostLens has made to your AWS infrastructure — with one-click rollback for reversible fixes.
Fix History is a complete, immutable audit log of every change CostLens has made to your AWS infrastructure on your behalf. Use it for change management, compliance reviews, and incident tracing. Reversible fixes can be undone with one click within 24 hours.
Fix statuses
| Status | Meaning |
|---|---|
| pending | Queued or currently executing in AWS |
| running | The fix (or a rollback) is actively executing |
| completed | Applied successfully — AWS confirmed the change |
| failed | Execution failed — check the error detail for the AWS error message |
| rolled_back | The fix was reversed and the resource restored to its previous state |
What is logged for each fix
- Which recommendation triggered the fix
- The AWS resource affected (ID, type, region)
- Who approved the recommendation
- Who applied the fix (operator/admin user)
- Timestamp of execution
- The before and after state captured at execution time
- Output message or error returned from AWS
- If rolled back: who rolled it back and when
Audit trail
Use Fix History during audits or incident reviews to trace exactly what was changed, when, and by whom. Every entry is append-only and cannot be deleted.
Rolling back a fix
CostLens captures the resource's before state every time it applies a fix. For reversible fixes, this lets you undo a change with a single click and restore the resource to exactly how it was — within a 24-hour window after the fix completed.
Which fixes can be rolled back
| Fix type | Rollback action |
|---|---|
| EC2 Rightsizing | Restores the original instance type (stop → change type → start) |
| EBS gp2 → gp3 Migration | Migrates the volume back to gp2 (respects AWS's 6-hour modification cooldown) |
| EC2 Instance Scheduling | Deletes the EventBridge schedules and removes the schedule tags |
| RDS Instance Scheduling | Deletes the EventBridge schedules and removes the schedule tags |
| Idle RDS Database (stop) | Starts the database again |
| CloudWatch Log Retention | Removes the retention policy (restores logs to never-expire) |
Fixes that cannot be undone
Some fixes permanently delete or release resources and cannot be reversed by CostLens. These show a "Cannot undo" badge in Fix History:
| Fix type | Why it's irreversible |
|---|---|
| Unused EBS Volume (delete) | The volume and its data are permanently deleted |
| Orphaned EBS Snapshots (delete) | The snapshot is permanently deleted |
| Unattached Elastic IP (release) | The IP is returned to AWS; a new one would have a different address |
| Stopped EC2 Instance (terminate) | The instance and its attached volumes are permanently deleted |
Take your own backup first
Before applying an irreversible fix, ensure you have your own snapshot or backup of any data you wish to keep. CostLens shows a clear warning in the Approve dialog and in Fix History for these actions.
How to roll back
Open Fix History
Go to the Fixes page. Completed fixes that can still be rolled back show a Rollback button and a countdown badge (e.g. "18h to rollback").
Click Rollback
Click the Rollback button on the fix row. A confirmation dialog shows what will be restored and when the rollback window closes.
Confirm
Click Confirm Rollback. CostLens reverses the change in your AWS account using the saved before-state and sets the fix status to rolled_back.
Recommendation reopens
The original recommendation returns to the open list so you can review it again or take a different action.
Rollback is available to Operators and Admins (the same roles that can apply fixes). Read-only organisations cannot roll back. Every rollback is recorded in your organisation's audit log with the actor and timestamp.
After the 24-hour window
Once 24 hours have passed since a fix completed, the Rollback button disappears. The change remains in place. To revert it after this point, apply the equivalent change manually in AWS, or — for schedules and rightsizing — re-run the relevant CostLens recommendation in the opposite direction.
Why 24 hours?
The window keeps the saved before-state relevant. AWS resources drift over time — restoring a multi-day-old instance type or schedule could conflict with changes made since. A 24-hour window keeps rollback safe and predictable.