> ## 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.

# What happens when an emergency is triggered in Rekkeh

> Learn the full emergency chain in Rekkeh from trigger to resolution, including the four trigger paths, who gets notified, SLA tracking, and the three audit records left behind.

When an emergency is triggered, Rekkeh runs one operational chain that takes an alert from the moment it is raised to a closed, fully recorded response. This article walks each stage in order so you can see what the security team sees and what gets recorded at every step.

<Steps>
  <Step title="Trigger: how an emergency is raised">
    An emergency starts when someone raises an alert through one of four paths. Every path creates an alert with severity **Critical**.

    * **Member Safety screen** — tap **Emergency Alert**, then **Send Emergency**. This sends a normal emergency alert and attempts to include the member's foreground GPS coordinates; a location failure or permission denial does not prevent the alert from sending.
    * **Member Security / Alerts screen** — press and hold **Hold to Alert** for exactly 1,400 ms. Releasing early cancels the hold and sends nothing. This raises a silent alert so the member's phone does not draw attention.
    * **Gate Ops duress PIN** — entering the duress PIN unlocks the app while covertly creating a duress emergency. The incident description is recorded as "Guard duress PIN entered — covert response required", and the reporting guard is excluded from the notification recipients so their own phone is not alerted.
    * **Estate admin manual alert** — from the emergency page, **Raise manual alert** then **Raise manual emergency**. You provide the subject or resident name, the unit or location, and a description up to 500 characters, then **Dispatch alert**. The confirmation reads "Emergency alert created and dispatched to staff."
  </Step>

  <Step title="Alert and notification: who gets told">
    Rekkeh immediately requests in-app and push delivery with critical priority to the active roles **Estate Manager**, **Platform Admin**, **Guard**, and **Security**. The notification text depends on how the alert was raised:

    * **Normal or silent alert** — the reporter's name and unit, followed by "needs immediate assistance".
    * **Manual alert** — the reporter's name and unit, noting it was raised by the named actor (or "admin").
    * **Duress alert** — the guard's name and gate or unit, warning they "may be under duress — respond covertly".

    The emergency SLA defaults to five minutes. SLA notifications target Estate Manager and Super Admin with the messages "Emergency SLA breached", "Emergency alert not acknowledged within SLA", and "Emergency alert still unresolved — supervisor escalation". When the alert's SLA is breached, Rekkeh also attempts email and SMS delivery where the flags and contact details allow. Notification preferences can suppress in-app or push delivery, and quiet hours can skip or defer push.
  </Step>

  <Step title="Acknowledgement: confirming eyes on the alert">
    **Acknowledge** is the first responder action. It confirms someone on the team has eyes on the alert and stops the SLA clock, so the countdown no longer applies.
  </Step>

  <Step title="Response: dispatch and arrival">
    Once acknowledged, the team works the alert to the scene. **Dispatch / En route** notifies the assigned responder immediately, and **Mark arrived** records that the responder reached the reported location. Each step moves the alert to its next status and is written to the timeline.
  </Step>

  <Step title="Resolution: closing the live response">
    **Resolve** closes the live emergency response. It requires confirmation: the dialog warns that resolving closes the live emergency response and should only be confirmed when the situation is under control, and offers the choices **Resolve** or **Keep alert**. Once resolved or cancelled, no further action buttons appear.
  </Step>

  <Step title="Audit trail: the records left behind">
    An emergency leaves three distinct records. They are separate surfaces, not one merged log:

    * **Emergency response timeline** — the per-alert record of every action, who took it, and when, ordered oldest first. Events include Raised, Acknowledged, En route, Arrived, Resolved, Cancelled, Note added, SLA breached, and Escalated to supervisors.
    * **Incident audit tab** — the facility audit rows tied to that incident, shown newest first.
    * **Facility Audit Log** — the organization-scoped record of admin activity across the facility.

    SLA breach and escalation appear as timeline events; they are not entries in the facility audit log.
  </Step>
</Steps>

## What's next

* To work an alert through the response chain, see [Respond to an emergency](/security/respond-to-emergency).
* For the two covert trigger paths, see [Panic and duress](/security/panic-duress).
* To compare the three security records, see [Audit trail](/security/audit-trail).
* For SLA and escalation settings, see [Safety and emergency settings](/getting-started/safety-emergency-settings).