The audit log
What this covers
The record of security events in your workspace: what is in it, how to filter it, and how to use it when
something looks wrong. Requires the manage-settings permission. At
Property Settings → Audit log (/settings/audit-log).
It is read-only. Nothing here can be edited or deleted, by you or by anybody else, which is what makes it worth having.
What is recorded
Security events concerning accounts and access — not day-to-day restaurant activity.
| Area | Events |
|---|---|
| Signing in | Successful sign-ins, failed attempts, lockouts, lockouts cleared, sign-outs |
| Passwords | Changed, reset, a reset requested, and a rejection because the password was found in a breach |
| Two-factor | Enabled, confirmed, disabled, a failed challenge, and a recovery code being used |
| Network access | Allowlist changes, blocked attempts, and bypass codes being issued, used or revoked |
Each row shows who (name and email), what, when, from which address, and any extra detail the event carried — how long a lockout was, which address was blocked, how many uses a bypass code had.
What is not in here
This log is about access, not about bookings. Changes to a reservation or a guest are recorded against that record's own history, which is a different and more detailed thing (link Editing and rescheduling).
So "who moved this booking to Thursday?" is a question for the booking's history. "Who signed in at 3am?" is a question for here.
Filtering
Five filters, combinable, with 50 entries per page:
- Category — the broad grouping. Everything is access-related today
- Event — one specific kind, such as failed sign-ins only
- Staff member — everything concerning one person
- Date from and Date to
Filtering by event is how this becomes useful rather than a wall of sign-ins. Choose failed attempts alone, over a fortnight, and the pattern is immediately visible.
Investigating a suspicious sign-in
A worked method. The point is to establish whether something is a person forgetting a password or somebody trying to get in.
1. Start with the failures
Filter to failed sign-ins over the last week or two. Look at:
- How many, and how fast. Three over a minute is a person. Forty in sequence is not.
- The time. Attempts at 04:00 on a closed day deserve a second look.
- The address. Repeated attempts from one unfamiliar address, especially against several accounts, is the clearest signal available.
- Which accounts. One account is probably its owner. Several in sequence is somebody working through a list.
2. Check whether anything succeeded
Switch to successful sign-ins over the same period. This is the question that matters. Compare each against what you know: was that person working? Is that address one you recognise?
A success from the same unfamiliar address that produced the failures is the outcome you are looking for — and the one that needs acting on immediately.
3. Look for what came next
If you find a suspicious success, look at what followed it in the log. Password changes, two-factor being disabled, allowlist entries added, bypass codes issued — anything that would extend or entrench access.
4. Act
- Change that account's password immediately (link Editing and removing staff).
- Turn on two-factor for it, which makes the password alone useless (link Two-factor authentication).
- Check the account's role — work out what could have been reached.
- Review your staff list for accounts you do not recognise.
- Revoke bypass codes and check allowlist entries for anything you did not add (link Bypass codes).
- Report it, with the dates and addresses you found (link Reporting a problem).
Other things worth checking here
- Before deleting a staff account. Once deleted, records they created no longer name them — so if attribution might matter, read the log first (link Editing and removing staff).
- When somebody says they never got locked out. The log settles it.
- After a Manager leaves. Check their last few shifts, not from suspicion but because it is much harder to reconstruct later.
- When two-factor is disabled unexpectedly. Only the account holder can disable their own, so an unexplained event here is worth a conversation.
- Periodically, for a few minutes. Failed sign-ins and blocked attempts are the two lists where a pattern shows up long before anything goes wrong.
Good to know
Password rejections are recorded, not passwords. When a password is refused for appearing in a breach, the log notes that it happened. No password is ever stored or logged.
A sign-in by Tabledoo support is marked as such. It appears as a normal sign-in carrying an extra note identifying the support session — deliberately, so an unfamiliar address at an odd hour is not mistaken for an intruder (link When support signs in to help).
Nobody can tamper with it. There is no edit and no delete, for any role.
Your own actions are in here too, including unlocking somebody — which is the point of an audit log rather than a shortcoming.