# Emergency alerts

The fixed SOS button opens a dialog with three private, automatically saved contacts. International-format mobile numbers and three different nominees are required. The sending action is enabled only after changes have saved and the server confirms a sending service is configured.

Automatic sending requires a production SMS provider account and approved sender. This implementation uses Twilio's HTTPS Messages API. Set TWILIO_ACCOUNT_SID and TWILIO_AUTH_TOKEN as Sites runtime secrets, and TWILIO_FROM_NUMBER to the approved SMS sender, then deploy a saved version. Keep credentials out of source and browser code. Before enabling for launch, verify the sender's ability to send to the intended destination countries, provider account limits, billing and consent with the provider. Coordinate any real test with the consenting nominated contacts; do not send unsolicited test alerts.

The server authenticates the current user and reads contacts from their saved plan. It rejects missing configuration rather than simulating notifications. It validates location freshness, records an idempotent alert claim before contacting the provider, limits sending to once per minute per user and reports each provider submission independently. SMS submission is not proof of delivery or that a person responded. Ambiguous timeouts are marked unconfirmed and never automatically retried. Alert records store statuses, not location or message bodies; the provider necessarily receives the location included in the SMS. No continuous tracking is performed.

Location permission is requested at the sending action, with a ten-second timeout. An unavailable location does not block the help message. Phone call links and individual SMS composers remain available, including without the automatic provider. The user must send each composed phone message. The UI explicitly states that it does not dispatch or monitor emergency services.

Verification: node tests/emergency.test.mjs uses a mocked provider and database; no live alerts are sent. It covers contact/location validation, authentication, configuration, partial failure, truthful submission status, idempotency and cooldown. A consenting end-to-end provider and mobile-device test is still required before launch use.