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

# Resolve an emergency alert and close the live response

> Learn what resolving means, when to resolve an emergency, what records it creates, and how resolution differs from cancellation in Rekkeh.

Resolving an emergency closes the live emergency response and marks the alert as handled. It is the final step a responder takes once the situation is under control, and it writes the resolution into the alert's timeline and the incident's audit record.

## What resolving an emergency means

Resolution is the terminal step in an alert's lifecycle. In Rekkeh's status model, **resolved** is the end state an alert reaches after it has been worked: an open alert can be acknowledged, cancelled, or resolved; an acknowledged alert can move to en route or resolve; an en-route alert can mark arrived or resolve; and an arrived alert resolves. Once an alert is resolved, no further action buttons appear and the detail screen shows **Resolved** with the resolution time.

## When a responder should resolve

Only resolve once the situation is actually under control. Resolving closes the live emergency response, so a responder should not do it while the emergency is still active. Because it is a staff action, the reporting member cannot resolve an alert; a member can only add details or cancel.

In Gate Ops, the **Resolve** action requires confirmation. The confirmation 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**. Choosing **Resolve** marks the alert resolved; choosing **Keep alert** leaves it in its current state.

## What resolution does to the live response

Resolving sets the alert's status to **resolved**, records the time it was resolved and who closed it, and saves any resolution note you supplied. The alert is no longer treated as live, so the live-location card stops showing an active response and the detail screen replaces the action buttons with a closed card that shows **Resolved** and the resolution timestamp, plus the resolution note when one was recorded. A confirmation toast confirms the incident is now marked resolved.

## What records resolution creates

Resolving writes to two of Rekkeh's security records:

* **Emergency response timeline** — a **Resolved** event is added to the alert's response timeline, showing who resolved it and when.
* **Incident audit tab** — an `emergency.resolved` audit action is recorded on the incident, with the actor role, timestamp, and metadata.

Together these leave a complete audit trail of the resolution, so you can see exactly who closed the alert and when.

## Resolution vs cancellation

Resolution is not the same as cancellation. Cancellation closes an alert that was never responded to: only the original reporting member can cancel, only while the alert is still open, and only within two minutes of raising it. Resolution closes a live response after it has been handled and is done by a staff responder. A cancelled alert shows **Cancelled** on its detail screen and records `emergency.cancelled` in the audit tab, while a resolved alert shows **Resolved** and records `emergency.resolved`.

## What's next

* For the step-by-step workflow a responder follows to get an alert to resolution, see [Respond to an emergency](/security/respond-to-emergency).
* For the full chain from trigger to resolution, see [What happens when an emergency is triggered](/security/what-happens-when-emergency-triggered).
* To learn about the three security records, see [Audit trail](/security/audit-trail).