An append-only audit trail
When a bill lands in the wrong place, the first question is always the same: what actually happened? ml-connector answers it with an append-only log of every meaningful action, scoped to your workspace, attributed to an actor, and ordered by time.
What gets logged
Audit coverage follows the things that can change your data or your money. Every entry records the actor, the action, the entity it touched, and when it happened:
- Credentials created, rotated, and deleted
- Flow runs started, completed, and failed, including the canonical mapping stage
- Schedules, risk tiers, and field mappings changed
- Webhooks received and webhooks processed, as two separate events
- Failed records retried and resolved
- Alerts dispatched, and the environment suspended or resumed
- Scheduled retention cleanup, with the counts it removed
Append-only by design
Entries are written once and never edited. There is no update path in the code, so there is no supported way for an entry to be revised after the fact. The only thing that ever removes an entry is scheduled retention, on a published window.
Every action names who did it
An entry without an actor is a rumour. Every action carries an identity, and work performed on your behalf through the control plane records the specific operator rather than a generic system label, so support activity is as traceable as your own.
Bounded so one caller cannot flood it
Audit metadata is capped at 16KB per entry. Anything larger is stored as a truncation envelope that records the original size and keeps a preview, so a runaway job degrades a single entry instead of filling the table. The audit trail stays readable under exactly the conditions that make you want to read it.
Auditing never breaks your integration
If an audit write fails, the flow it was recording carries on and the failure is reported separately. Logging is a record of the work, not a gate in front of it, so an audit problem can never become a reason your invoices stopped moving.
How long entries are kept
Audit entries are retained for 180 days by default, longer than run history, and are then removed by the same scheduled cleanup that handles everything else. The window is configurable per environment.
Common questions
- Can an audit entry be edited or deleted?
- There is no update path in the product, so entries are not revisable. Scheduled retention is the only process that removes them.
- How long is the audit trail kept?
- 180 days by default, and the window is configurable for your environment.
- Does the audit trail contain my credentials?
- No. Entries record the action and the entity it affected. Credential fields are redacted automatically, so a secret cannot reach the log through metadata.
- Can I see what a support engineer did in my workspace?
- Yes. Work done on your behalf through the control plane is attributed to the specific operator, in the same trail as your own actions.
- Where does the audit trail physically live?
- In your own environment's database, alongside your flows and run history, not in a shared logging system.
Keep reading
Still have a question?
Start a chat and a real person will answer it. No ticket queue.