Audit log
Who did what, across every team in your business, and how to get it out.
The audit log records what people did in your business: signing in, joining and leaving teams, changing what a dashboard shares, connecting and removing data sources, and the billing that follows. Each entry names the person, the team, the time and whether it worked.
Available on the Business plan. See Billing.
Before you start
You will need:
| A business on Flitch | The log spans every team the business owns, so it belongs to the business rather than to a team. |
| The owner or admin role | On the business itself. A team admin who is only a business member cannot read it. |
Open Settings → Business → Audit log. The tab is not shown to people who cannot read it.
Read it
Newest first, one line per event, with the full record a click away. The filters are the ones you reach for after something has happened:
- Search by person or by the kind of event.
- Last 7, 30 or 90 days, or everything recorded.
- Failures, which is usually the first thing you want after an incident.
- Team, when the business owns more than one.
- Oldest first, for reading a sequence forwards once you know roughly when it began.
Two things are hidden by default and can be switched on with Include activity: data reads and dashboard errors. Data reads alone are the large majority of all events, and an export where sign-ins are buried under a page-view log answers no question anyone asked.
Export it
Export offers three formats, for three readers:
| Format | For |
|---|---|
| CSV | Opening in a spreadsheet |
| JSON | One event per line, for a script |
| OCSF | Your SIEM |
OCSF is the Open Cybersecurity Schema Framework, the schema AWS, Splunk and CrowdStrike built together. Choosing it means your security team ingests Flitch events without anyone writing a parser for a shape only we use.
Whatever is filtered on screen is what the file contains. The screen and the file cannot disagree.
Stream it to a SIEM
For continuous ingestion rather than a file, poll GET /api/v1/audit with a key holding the audit:read scope.
It hands back each event exactly once. Send the cursor from the previous response and you get what has happened since; keep going while hasMore is true, then poll on whatever cadence suits you.
The feed is deliberately a few seconds behind the present, which it reports as lagSeconds. An event carries the timestamp of the process that wrote it, so a row can arrive stamped slightly earlier than one already sent, and reading up to a horizon rather than to the clock is what stops the cursor stepping over it.
audit:read is the one scope that reaches past the space its key belongs to, and it is checked against the person who created the key on every request. A key stops working the moment its creator is no longer a business admin.
How long events are kept
Audit events are kept for 365 days. Data reads and dashboard errors, which are diagnostics rather than a record of what someone did, are kept for 90.
The viewer states both, along with the date your record begins. Nothing from before audit attribution was added carries a business, and it cannot be given one, so a short log says it is short because recording started rather than because nothing happened.
When Flitch support needs access
Our staff cannot let themselves into your space. Support asks, an admin of that space approves from Settings → Security, and the access expires by itself. The request, your answer, and the access ending are all in this log, and you can end it early at any time.
In an emergency, such as nobody being able to sign in to approve, access can be opened without waiting. It lasts one hour, you are emailed the moment it happens, and it appears here at critical risk like anything else.