Global Alarm: Give Your Swarm a Clock and Your Memory a Day Off.

“I’ll remember to check that on Friday.”

A bold deployment strategy. No persistence layer. No retry policy. Powered entirely by a person who currently has seventeen terminal tabs open and cannot remember which one contains production.

Global Alarm gives that future task a place to live. Create a reminder in Phoenix, save it to the MatrixOS agent, and let the running swarm send it through your configured alert relays when it becomes due. Close Phoenix afterward: the schedule lives with the agent.

The condition matters: MatrixOS and the required relay agents must keep running. Closing the cockpit is fine. Shutting down the machine hosting the swarm is a rather more enthusiastic interpretation of “day off.”

Global Alarm is currently marked provisional — QC testing needed in the agent reference. Start with a test reminder and confirm the complete delivery path before depending on it.

The useful jobs are wonderfully ordinary: a weekly backup review, a maintenance-window heads-up, a daily handover reminder, or a one-time nudge to revisit that temporary workaround that has started receiving anniversary cards. Global Alarm schedules messages. The operator still performs the task described in the message.

You choose a title, message, local date and time, IANA time zone, and recurrence: once, daily, or weekly. Each reminder also names a service role. At the due time, Global Alarm discovers matching agents and queues the reminder to them. Telegram, Discord, and email relays can carry it to the places you already check.

That division of work keeps the setup small: Phoenix edits the schedule, Global Alarm keeps time and state, and a relay handles the external service.

For a first swarm, use the Matrix root with matrix_https for command ingress, matrix_websocket for Phoenix replies through hive.rpc, global_alarm, and telegram_relay. You can add discord_relay or email_send later. Add log_streamer if you also want streamed agent logs in Phoenix; Global Alarm’s schedule and panel replies use their own command and callback paths.

Here is the setup sequence:

1. Prepare the host. If MatrixOS is not installed, open Install MatrixOS… in Phoenix to launch Railgun’s installer. Select the intended SSH target and use Install from GitHub, or Local Full Install with the matrixos directory from your checkout. Complete the install and check its result before deploying a swarm. Use matching, current Phoenix and MatrixOS sources. The deployed Global Alarm package must include both global_alarm.py and engine.py; shipping only the entry point leaves the scheduler’s engine at the station.
2. Build or edit the swarm in Swarm Workspace. Add the agents above and configure their required Registry assignments, transport addresses, and certificates. Keep the WebSocket agent’s hive.rpc@cmd_rpc_route service available so Phoenix can receive the alarm panel’s replies.
3. Give Global Alarm its identity and storage. Resolve its packet-signing constraint in both directions and assign a dedicated persistent_state Registry record. Signing keys support authenticated communication with Phoenix; the persistent-state assignment supplies the stable storage identity and encryption material. Keep that record, state ID, key, and universe consistent across redeployments so the agent can find and decrypt its saved reminders.
4. Configure the relay. Assign the Telegram bot credentials and destination chat, or the appropriate Discord or SMTP configuration. Ensure alerts are enabled. In the relay’s Service Manager Roles editor, add the reminder role described below.
5. Set Global Alarm’s defaults. Its configuration editor provides Check interval (seconds) and Default alert to role. The check interval defaults to five seconds and supports one through sixty. For this example, set the outgoing role to hive.alarm.telegram. Individual reminders can override it.
6. Deploy with Railgun and connect. Complete the workspace deployment assignments, review the resulting configuration, and launch the deployment to your selected host. Railgun streams the sealed deployment envelope over the pinned SSH channel to MatrixD, which decrypts it in memory and boots the swarm. Connect Phoenix to the deployed swarm, select Global Alarm, and open its clock panel.

The next detail is small enough to miss and important enough to ruin your afternoon: the sending role and receiving role must match.

In the Telegram relay’s Service Manager Roles, advertise:

hive.alarm.telegram@cmd_send_alert_msg 

In Global Alarm’s default, or the reminder’s Alert to role field, enter:

hive.alarm.telegram 

The relay advertises the role plus its handler. The reminder specifies just the role, without @cmd_send_alert_msg. The discovered endpoint supplies the handler.

Want one reminder to reach Telegram, Discord, and email? Configure all three relays to advertise a shared role such as hive.alarm.ops@cmd_send_alert_msg, then send the reminder to hive.alarm.ops. Global Alarm queues a copy to each discovered matching listener. For a narrower audience, give only the intended relay a dedicated role.

The default hive.alert can work too, but it may have other listeners in your swarm. A dedicated reminder role makes the audience easier to control. “Everybody got it” is useful only when everybody was on the invitation list.

Now create something useful. In the Global Alarm panel, choose New and fill in a reminder like this:

Click Add / Update Draft, then Save Changes. You can also save directly after editing the form; Save Changes stages the current form before sending the complete list. Wait for the save acknowledgment. A draft sitting in the editor has approximately the same operational authority as a sticky note still attached to its backing paper.

Select a saved row to edit it. Use New for another reminder, Delete to remove one, and save again to commit those changes. Reload Saved fetches the agent’s stored list and can discard unsaved work after confirmation. If another panel saved a newer revision, your conflicting save is rejected until you reload.

The alarms belong to this agent. Authenticated Phoenix operators who can manage it share the same alarm list; there are no separate private lists for each operator.

Time zones deserve their own moment of respect. A weekly 09:00 reminder follows 09:00 in the selected IANA zone, even when its UTC offset changes. The server’s default zone does not silently replace the reminder’s zone. The panel displays the server clock and refreshes it while connected; it labels the display stale when fresh reports stop arriving.

Daylight-saving behavior is explicit: an initial time inside a spring-forward gap is rejected; a future recurring occurrence inside that gap is skipped. If a local time occurs twice during fall-back, the first occurrence is used. “Twice a year we negotiate with the sun” remains a remarkably durable software requirement.

If the agent was stopped when a reminder became due, it queues the missed reminder after resuming. Missed recurring occurrences are combined into one catch-up reminder, then the schedule advances to the next future occurrence. You get a nudge, rather than a historical reenactment of every Friday you missed. Disabled reminders do not fire; re-enabling an overdue one can queue it immediately. Changing a schedule re-arms the alarm.

The panel’s status tells you where the work stands:

If no listener is found, the occurrence stays pending and discovery is retried. Once listeners are found, their IDs are saved for that occurrence. A failed queue attempt remains pending, while destinations already recorded as queued are normally skipped on retry.

Saved confirms encrypted agent storage. Queued confirms a handoff to a relay. Neither is a receipt from your phone or inbox. A relay can be disabled, misconfigured, or fail after accepting the packet. Global Alarm does not implement downstream delivery receipts or exactly-once delivery; a crash after queueing but before recording success can cause a duplicate retry. Keep that distinction in mind when reading the status column.

Reminders are stored in encrypted persistent state. Telegram, Discord, and email also support optional signed alert-payload encryption through the relay’s encrypt_alerts setting and assigned key material. That is a separate choice from storage encryption. Configure the matching decryption workflow and test it if you enable the option; ordinary chat and mail clients do not magically turn the encrypted payload back into readable text.

The current limits are 200 alarms and 2,000 characters per message, with titles up to 120 characters. Between the polling interval and the relay’s delivery path, this is a practical reminder scheduler rather than a precision timing instrument.

Before handing it your real schedule, create a one-time reminder a few minutes ahead. Save it, close Phoenix while leaving the server swarm running, and confirm the message arrives at the intended destination. Reopen Phoenix and inspect the saved state. Repeat the test for each relay you plan to use. That short exercise proves much more about your setup than admiring a correctly spelled service role.

Once that works, give the swarm the weekly backup check, the maintenance heads-up, and the follow-up you keep carrying around in your head. Your memory can spend its day off remembering something pleasant. Like where you put the coffee before opening terminal number eighteen.

For the implementation details, see the Global Alarm agent reference and Phoenix walkthrough.

Victory Always.

🌐 Links & Resources:

• MatrixSwarm source — MatrixOS and Phoenix
• Try MatrixSwarm
• Join the Community / Discord
• YouTube