Change timeline
The change timeline (/changes) is the answer to “what happened to this, and who did
it”.
What feeds it
Section titled “What feeds it”Three sources land in one timeline:
| Source | What it contributes |
|---|---|
| AWS CloudTrail | Write activity in your accounts, with the principal that did it |
| Discovery revisions | Configuration differences Aletheia observed between scans |
| Aletheia’s own audit log | Changes people made in Aletheia itself |
Your CI integration adds a fourth: deployments, recorded when an apply finishes.
Why merge them
Section titled “Why merge them”Each source alone is misleading.
CloudTrail tells you an API call happened but not whether it mattered. Discovery tells you a resource’s configuration differs but not who changed it. Your pipeline knows what it deployed but nothing about what happened outside it.
Together they answer the question people actually ask: did this change come from a pipeline, or did somebody do it by hand? A configuration change with no corresponding execution is a change made outside your automation, and that is visible here without anyone having to correlate logs.
Reading an entry
Section titled “Reading an entry”Every entry records what changed, when it occurred, and the actor where one is known. Assumed-role sessions are resolved back to the underlying principal, so a change made through a role does not read as an anonymous session.
Entries link to the resources they touched, and every resource and application page carries its own filtered timeline.
Filtering
Section titled “Filtering”Filter by time range, actor, resource, or application, plus free text. Filters are in the URL, so a filtered timeline is a link.
The timeline is append-only
Section titled “The timeline is append-only”Entries cannot be edited or deleted, by anyone, including administrators. The database rejects the attempt rather than relying on the application to be careful.
A change history that could be rewritten would not be worth reading during an incident, which is when it matters most.
Ingestion health
Section titled “Ingestion health”CloudTrail is polled per account and region, each with its own cursor. Administration
→ Ingestion (/admin/ingestion) shows the state of each one, how far behind it is,
and any error.
When a cursor fails, it stops advancing rather than skipping the window it could not read. Retry it from that screen once the cause is fixed; the gap is filled rather than lost.
Ingestion lag is normal in small amounts — CloudTrail itself delivers with a delay.
What is redacted
Section titled “What is redacted”Request payloads are recorded so you can see what a change contained, with sensitive fields removed before storage.
Where to go next
Section titled “Where to go next”- Plans and executions to add what your pipelines intended.
- Audit log for changes made inside Aletheia.