Monday, 9:03am. Someone asks the question that decides how the week goes: “anything change over the weekend?”
At most companies the answer is a ritual of confident shrugs. The deploy channel is quiet, so, probably not? Meanwhile the honest answer is that production definitely changed, because production always changes. The only question is whether you find out now, on your terms, or later, during an incident, on its terms.
Your pipeline is not the only author of production
The comforting story about change management is that everything flows through the deploy pipeline: PRs are reviewed, changes are announced, the channel is quiet, therefore prod is stable. The uncomfortable inventory reads differently. Consoles get clicked during emergencies. Autoscaling adds and removes capacity on its own schedule. Scheduled jobs rotate, expire, and occasionally fail to rotate. CI roles, including ones that should have been retired, keep writing. And increasingly, AI coding tools and agents provision infrastructure that no human ever announced anywhere.
A complete answer to “what changed?” therefore spans five separate ledgers: code deploys in your CI history, infrastructure changes in CloudTrail and its cousins, config and flag changes in their own audit logs, identity changes in IAM events, and cost movement, which is often the first observable symptom of all the others. Five ledgers, five timestamp formats, no shared timeline. That is why the Monday question gets shrugs: assembling the truth by hand costs an hour nobody has at 9am.
The changes that matter most are the ones outside the pipeline
Here is the pattern that shows up whenever we run this question against a real environment: the changes worth talking about are disproportionately the ones that arrived outside infrastructure-as-code. The console edit made during Friday’s near-miss and never backported to Terraform. The resources created by a CI role attached to a project that ended. The load balancer that drifted from its definition three weeks ago and has disagreed with the map ever since.
Drift is not an aesthetic problem. Your team reasons from the code; every drifted resource is a spot where reality and the map disagree, and disagreements between reality and the map are where incidents breed. Finding drift requires comparing IaC state against live state and attributing each gap to a creator and a mechanism, which is graph work, not grep work.
Clean changes are information too
One underrated detail: a good answer to “what changed?” includes the innocent changes. “Four changes since Friday: two clean deploys, one Terraform apply, and one capacity rule update, and the capacity change is what moved the bill” is a complete answer. Knowing that three of four changes are boring narrows every investigation that follows this week. Change visibility is not only about catching problems; it is about being able to exclude non-problems quickly, which is most of what diagnosis is.
Making the question cheap
Everything above can be done manually, and after major incidents, it usually is, once. The trick is making the question so cheap that it gets asked daily.
This is exactly the shape of work Oscar was built for. Because it maintains a live context graph with the change history woven in, “what changed in prod since Friday?” is one question, answered in one timeline: each change attributed to a person or a mechanism, flagged as routine or unusual against your environment’s own patterns, with drifted resources called out and traceable to how they got that way. Anything suspicious becomes a task with the evidence attached rather than a Slack thread with a screenshot.
When the question costs one command, teams ask it every morning, and drift stops accumulating because it gets caught the day it appears, not the quarter it causes an outage.
Try the ritual this Monday. Ask the room what changed since Friday, and time how long a complete answer takes. If the answer is measured in hours or in shrugs, give Oscar thirty minutes and ask it instead.
Key Takeaways
Key points
- ✓Production changes continuously, and only part of it comes from your deploy pipeline: consoles, autoscaling, pipelines, and AI tools all write to prod.
- ✗A complete answer spans code deploys, infrastructure changes, config and flag changes, identity changes, and cost movement, five ledgers with no shared timeline.
- ✗Changes that arrive outside IaC are the dangerous ones: console edits, retired CI roles still writing, and agent-created resources.
- ✓Clean deploys matter as much as dirty ones: knowing four things changed and three are innocent narrows every future investigation.
- ✓When change review is cheap, it becomes a daily habit instead of a Monday ritual, and drift stops accumulating.