> ## Documentation Index
> Fetch the complete documentation index at: https://help.rekkeh.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rekkeh security audit trail: three records explained

> Rekkeh keeps three separate security records. Learn which one to use for emergency responses, incident history, and facility-wide administrative changes.

Rekkeh keeps three separate security records, not one merged audit trail. Each answers a different question and is read in a different place. Use this page to identify which record you need.

## The three records at a glance

| Record                      | What it covers                                               | Where to read it           | Order        |
| --------------------------- | ------------------------------------------------------------ | -------------------------- | ------------ |
| Emergency response timeline | Actions on a single emergency alert, from raised to resolved | The alert's detail screen  | Oldest first |
| Incident audit tab          | Audit rows for one incident record                           | The incident's `audit` tab | Newest first |
| Facility Audit Log          | All audited activity across the facility, filtered by type   | The Audit Log page         | Newest first |

## Emergency response timeline

The **Response timeline** is the per-alert record of every action, who took it, and when. It includes: Raised, Acknowledged, En route, Dispatched, On scene, Resolved, Cancelled, Responder assigned, SLA breached, and Escalated to supervisors. The actor is shown by name when available, otherwise by role, and falls back to **System** for automatic events.

Before any action is taken, the timeline shows: `Nothing logged yet. Acknowledging or dispatching adds the first entry.`

<Note>
  SLA breach and escalation events appear only in the emergency response timeline. They are not entries in the Facility Audit Log.
</Note>

## Incident audit tab

Each incident record has an `audit` tab listing all audit rows for that incident, newest first. Each entry shows the action, the actor role, a timestamp, and parsed metadata.

Actions you may see include:

* `incident.created`, `incident.updated`, `incident.note_added`
* `emergency.acknowledged`, `emergency.en_route`, `emergency.arrived`, `emergency.resolved`, `emergency.cancelled`
* `emergency.duress_raised`, `emergency.manual_raised`, `emergency.note_added`

## Facility Audit Log

The **Audit Log** page records all audited admin activity across the facility. It lists up to 50 entries per page, newest first. Each entry shows the action, actor, entity type, a truncated entity ID, relative time, and expandable metadata.

Use the filters to narrow the list:

* **Action filter** — free text (e.g., `incident.updated`)
* **Entity type filter** — All types, incident, invite, access\_event, user, or visitor\_watchlist

<Note>
  Only estate managers and super admins can open the Audit Log. Emergency audit rows are stored as `incident` entities, so use the `incident` entity-type filter to find emergency activity.
</Note>

## Which record to use

| If you need to...                                                     | Use...                                                   |
| --------------------------------------------------------------------- | -------------------------------------------------------- |
| Trace one alert from raised to resolved, including SLA and escalation | Emergency response timeline on the alert's detail screen |
| See every audit row tied to one incident                              | The incident's `audit` tab                               |
| Search all admin activity at the facility by action or entity type    | The Facility Audit Log page                              |

## What's next

* [What happens when an emergency is triggered](/security/what-happens-when-emergency-triggered) — the full operational chain from trigger to resolution.
* [Understanding Incidents](/security/understanding-incidents) — the incident workflow and where to manage it.