Alarms and severity

On this page

Anchor dragPosition outside the swing circle.AlarmAnchor watchUnacknowledged21:02 UTC
Gusts above the reef pointReview the sail plan.WarningWindUnacknowledged20:47 UTC
House bank lowCharging needed.CautionBattery monitorActive20:15 UTC

Illustrative alert list, drawn by the shared component: priority first, then newest first within each priority. Each row includes its source, state and time reference.

Alert presentation is designed with reference to IMO MSC.191(79), MSC.302(87) and the OpenBridge instrument family. The application determines which condition merits an alert and owns its lifecycle. The kit presents that decision; a color, icon or animation does not establish the safety of a system.

01Priority has a meaningUse the shared alert mapping for operational urgency. Keep report categories, decorative emphasis and ordinary actions separate from alert priority.

02State is explicitShow the priority, cause, source and lifecycle state in words as well as the visual mark. Color and flashing are supplementary signals.

03Acknowledgment is confirmedA click requests acknowledgment. The presentation changes to acknowledged when the authoritative alert state confirms it.

Priority and presentation

Kit priority	Mark	Acknowledgment	Meaning in the presentation
`emergency`	Alarm mark	Required	Highest list priority; uses the alarm appearance
`alarm`	Triangle	Required	Alarm appearance and attention behavior
`warning`	Circle	Required	Warning appearance and lifecycle state
`caution`	Square	Not required	Active condition or cleared condition
`none`	No alert mark	Not applicable	Informational content; excluded from AlertList

PRIORITY_SPECS in the kit defines the shared priority colors and shapes. The vessel application's severity.ts maps board levels to that presentation: critical to alarm, time-sensitive to warning, active to caution, and passive content to information. Keep that application mapping out of generic kit components. A report category such as “risk” does not automatically select a maritime alert priority.

One flash policy, three tempos

Every flashing alert presentation shares one clock and one tempo table (resolveFlashingSpeed): an unacknowledged critical, alarm or high alert flashes fast, a warning or medium slow, a low very slow, and a rectified alert very slow as well. Caution and diagnostic never flash, and acknowledging stops the flash. The kit's own components flash only an unacknowledged alarm or emergency (PRIORITY_SPECS): a warning there is steady, and they pass the alert icon steady for it. The on phase carries the tempo, so a flashing alert stays coloured for most of its cycle; every tempo goes off for the same 400 ms, and all tempos light up together at the start of the slowest cycle. Pass the actual state and do not add page-specific animation. See Motion for the timing and reduced-motion responsibilities.

Acknowledge, silence and clear

State	What it establishes	What it does not establish
Unacknowledged	The alert requires acknowledgment	Whether anyone has heard or seen it
Silenced	Audible annunciation is temporarily silenced	That the cause is resolved or the alert is acknowledged
Acknowledged	The responsible system has recorded acknowledgment	That the hazardous condition has ended
Cleared / rectified	The cause has ended	That an outstanding acknowledgment has been completed

Unacknowledged

Silenced

Acknowledged

Rectified

One alarm's lifecycle; the surrounding row supplies the cause and state text

Keep an acknowledged active condition visible where the alert policy requires it. A cleared, unacknowledged condition can require a distinct retained state; do not remove it solely because the sensor returned to normal. The application decides retention and history. The component neither clears a condition nor starts or stops audio.

acknowledgeAction runs the request and gives it pending feedback. Its completion does not substitute for the updated state or acknowledged prop. If the request fails or the connection drops, preserve the authoritative state and give the crew a clear recovery path.

Ordering and stable identity

AlertList groups emergency, alarm, warning and caution in that order, with newest first inside each group. It copies and sorts its input, uses each alert's stable id, and applies new ordering immediately without animation. With a limit it exposes the number of additional alerts. Do not label a partial list as the complete alert load.

A history or incident report can use chronological order to explain events. Label that view as history and keep its time reference visible. Replayed events do not participate in the live acknowledgment flow.

Choosing a presentation

Use Alert list for a compact operational overview and Alert card when explanation, delivery status or response advice needs more room. Use Alert zone for the top-level alert summary. Avoid constructing another alert row from colored borders, Unicode shapes and an unrelated button.

Anchor drag21:02 UTC

Position outside the swing circle.

Acknowledged by Crew

Include the condition and its confirmation state. An acknowledged alarm remains identifiable.

Don't

Check this

A color without a priority word, condition or state cannot explain an alert.

Themes and reports

Priority remains recognizable through its mark and words in every theme. Night uses the theme's defined interface, instrument and alert roles; it is not a rule to recolor every visual red. Verify state distinctions in Night and Bright, including focused controls and a disabled or pending acknowledgment.

A report about an incident needs the observed state, timestamp and source. Use static acknowledged or historical examples where appropriate and label illustrative scenarios. Report tone roles can organize sections, but must not imply a live alarm or a certified operational assessment.

Data integrity: how a reading communicates uncertainty and loss of trust.
Motion: attention clocks, transitions and measured values.
Alert list row: lifecycle presentation and acknowledgment behavior.
Themes: the roles each presentation uses.