The modern pager: three professional uses for Prelay

A pager is not a feed. It is not a group chat, an inbox, or a system of record. It is a short signal that reaches the right person and asks for attention.

That is also a useful way to think about Prelay. It is a notification relay for Android: one HTTP request in, one encrypted notification on a phone. It is deliberately narrow. The value is not that it can do everything. The value is that it does one job without turning every alert into another place to check.

These are three professional patterns where that narrowness is a feature.

1. The newsroom pager

An investigations desk needs to reach reporters after hours. A source meeting moves to 21:00. A court filing lands earlier than expected. The message is short, time-sensitive, and meant for one person or a small duty group.

The source meeting is the sensitive one: the alert needs to say where and when, not who or what.

Email is the wrong shape for this. It lands in an inbox with everything else, invites a thread, and keeps a copy in places the newsroom may not want it. A workspace channel is also the wrong shape: it is a room, not a pager, and the alert competes with everything else in the room.

Prelay gives the desk a direct path instead:

1. The newsroom runs its own relay, or uses Prelay Cloud.
2. Reporters register their Android devices.
3. The duty editor sends one short request from a small internal tool, a script, or the CLI.
4. The phone shows the alert. There is no message history to browse later.

The newsroom keeps the routing policy and the relay. In a self-hosted deployment, the default Mode A trusts the relay to encrypt the message to the device. If the relay sits outside the newsroom’s trust boundary, use Mode B: the sender encrypts before the request leaves the machine, and the relay only routes ciphertext. Prelay Cloud accepts Mode B only.

FCM is still the delivery transport, as it is for any Android push notification. It receives an encrypted envelope, not the plaintext message.

What it replaces: the “did anyone see this?” layer around email and chat.

What it does not replace: secure document transfer, a source-protection system, or a newsroom’s editorial workflow.

Operational rule: keep source names, unpublished documents, and anything that identifies a source out of the alert itself. Use Prelay for the short operational signal — where to be, when, and what changed — not for the sensitive material.

2. The quiet on-call channel

A small engineering team does not always need a full incident-management platform. It needs the on-call engineer to know that the nightly backup failed, a certificate is about to expire, or the deploy job stopped halfway.

Those alerts often end up in a chat channel where they are either missed or become background noise. Prelay gives them a separate, one-way path to the engineer’s phone.

A CI job, uptime monitor, or cron wrapper can send one request:

curl -X POST https://relay.example.com/v1/notify \
  -H "Authorization: Bearer $PRELAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Deploy failed: api","message":"Rollback started. Check the pipeline before retrying.","priority":"high"}'

Use a token scoped to notify:send, not an admin token. Keep the relay self-hosted if the team wants to own the path, or use Prelay Cloud if zero-knowledge delivery matters more than running another service.

The important boundary is that Prelay is the last hop, not the incident room. It does not provide on-call schedules, escalation policies, acknowledgements, or an incident timeline. Those belong in the tools the team already uses. Prelay makes the final delivery short and direct instead of adding another dashboard.

Good fit: deploy failures, backup failures, expiring credentials, a single cron job that needs a human.

Bad fit: a noisy feed of every warning, a replacement for a full paging rotation, or a place to hold the incident record.

Operational rule: reserve high priority for messages that require action now. An alert channel that cries wolf becomes another muted channel.

3. The signal channel

Your phone is full of notifications. Most of them are not for you. The result is a phone that buzzes all day, with the handful of messages that actually matter buried somewhere in the stack.

Prelay is a way to send yourself the few things that deserve to interrupt you. A long migration finishes. A backup completes. A certificate renews. A script needs a human. You write the sender, choose the token, and decide what gets sent. There is no algorithm deciding what is important, and no third-party app asking for access to everything so it can guess.

The practical trick is on the phone: give the Prelay app its own notification channel and a sound you recognize. Android lets you treat that channel differently from the rest: a distinct sound, a higher importance, or an exception to Do Not Disturb. Because you control the source, that sound can mean “this is one of the few things I asked to hear.” Everything else can stay muted.

The message is still encrypted. In Mode B or on Cloud, it is sealed before it leaves your machine; in Mode A, the relay you run does the sealing. FCM carries the envelope, not the text. Even a note to yourself can reveal a hostname, a customer, or a schedule.

The point is not to replace every notification. It is to have one channel that stays worth checking.

What it replaces: the noisy mix of email, chat, and app notifications you skim and ignore.

What it does not replace: a task manager, a full monitoring stack, or a chat app. If you need a record, a conversation, or a dashboard, use a tool built for that.

Operational rule: treat the channel as a promise. If it pings, it matters. Send only what you would stop for.

What the three have in common

Each use case has the same shape:

• one-way;
• short enough to read on a lock screen;
• meant for a specific person or duty device;
• useful now, not as a record for later;
• separate from the inbox and the group chat.

That shape is why Prelay stays small. There is no message history, no analytics, and no profile of the recipient. The Android app decrypts the envelope and posts a local notification. The relay routes; it does not become another workspace.

When Prelay is the wrong tool

Prelay is not a chat app, an email replacement, an incident-management system, or an emergency service. It does not support iOS today. It is not a place for attachments, long instructions, or a searchable audit trail.

If the message needs a reply, a thread, an acknowledgement, a schedule, or a permanent record, use a tool built for that. If the message needs to cross a trust boundary without exposing its contents to the relay, use Mode B or Prelay Cloud.

The useful question is not “can this be a notification?” It is “is this a short signal that should interrupt someone, and nothing more?”

Trying the pattern

The setup is the same for all three cases:

1. Run the relay with Docker, or create a Prelay Cloud account.
2. Install the Android app and register a device.
3. Create a notify:send token for the sender.
4. Send one request.

curl -X POST https://relay.example.com/v1/notify \
  -H "Authorization: Bearer $PRELAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Duty desk","message":"Source meeting moved to 21:00. Use the side entrance.","priority":"high"}'

That is the whole integration. No SDK, no mobile push infrastructure to build, and no notification vendor reading the message.

The modern pager is not a return to a device with a belt clip. It is a deliberate limit: one short message, one clear recipient, and no reason to turn it into another feed.