Alarm Sender rings an alarm on your devices when something tells it to. This
page says exactly what that means for your data: what is stored, where, for
how long, and how to get rid of it.
This deployment · last updated 16 October 2026
Who we are
Alarm Sender is operated by Single Breath LLC. The console
lives at alarmsender.com; trigger URLs live at
alrm.sh, which serves triggers and a health check and nothing
else. This policy covers both, the mobile and desktop apps, and the browser
extension.
The short version
We store what the product needs to ring your alarms: your email address, a
hash of your password, the devices you have paired, the alarms you have
received, and the triggers you have made. There is no analytics, no
advertising, no tracking, and no third-party SDK in any client we ship.
We do not sell anything to anybody.
The honest caveat: your alarm history is kept until you delete
it. An alarm's title and message can say anything you put in it,
so treat that history as something you own and can clear.
Your account
| What | Why |
|---|
| Email address | Signing in, sending escalation notices when an alarm goes unanswered, and, on a paid account, reminders before its plan ends |
| Password, hashed | PBKDF2. The password itself is never stored and cannot be recovered from the hash |
| Sign-in sessions | Stored as a hash of the session id, so a stolen database does not yield working sessions |
| When the account was created, and whether it is suspended | Administration |
| Your plan: paid or complimentary, the date a paid plan runs to, and which renewal reminders have been sent | Deciding whether alarms ring, and not sending the same reminder twice |
The only email we send you is about your own alarms and your own account:
an escalation notice from alerts@alarmsender.com when a chime
asked to be escalated and nobody answered, and, if your plan is a paid one,
reminders from the same address before it ends and if alarms stop because
it has. There is no newsletter and no marketing email.
Your devices
Pairing a phone, desktop or browser records a name you can change, the
platform it reported (android, linux,
windows, chrome, firefox), when it
paired, and when it last checked in. The pairing credential is stored as a
hash; the token itself exists only on your device.
A device's name is generated from the platform — "Firefox on Linux x86_64",
"Pixel 9" — and you can rename it. We do not collect an advertising ID, a
hardware serial, an IMEI, or any other device identifier.
Your alarms
Every alarm is recorded: which chime rang, its title and message, any
variables the trigger passed, which trigger or agent fired it, how many
devices it reached, and when. Alongside it we keep one receipt per device —
whether it rang, was silent, or was muted, and whether somebody
acknowledged or dismissed it, with the time from both the device's clock and
ours.
That history is what the Activity page shows, what escalation decides on,
and what tells you an alarm reached nothing. An alarm's title and
message contain whatever the sender put there, which may be
anything from "gate opened" to the contents of a monitoring alert.
Triggers and who fired them
A trigger stores its name, a hash of its token, the mapping that turns an
incoming request into an alarm, and its rate limits. Two things about the
callers are kept, and only the most recent of each, so nothing accumulates:
| Field | What it holds |
|---|
| Last caller address | The IP address of the most recent request to that trigger |
| Last refused sender | The address of the most recent email a sender allowlist turned away |
Both exist to answer one question — whether a refusal was a misconfiguration
or somebody who should not be there — and each is overwritten by the next.
We also count refusals by reason, without keeping a log of them.
Captured requests
This is the most sensitive thing the service can hold, and it is
off by default. When you switch capture on for a trigger so you
can build a field mapping, the next requests are stored whole: method,
query string, headers and body. Up to ten are kept per
trigger, oldest discarded.
Headers can include credentials the calling system sends. Turn capture off
once the mapping is built, and delete the captures you no longer need.
What stays on your device
The apps keep some things locally that are never uploaded: your cached
chimes, your device-side settings, a short list of recent alerts for the
history screen, and your Senders list — the shared alarms
you can ring. Senders live only on that device, which is why they survive
unpairing and why losing the device loses the list.
What you send to somebody else lands on their account, not
yours. Ringing a shared alarm sends whatever you typed to the
person who gave you that trigger: it is stored in their alarm history and
shown on their devices, and they can read it there afterwards. You hold
the trigger; they hold the record. Treat it the way you would any other
message to them.
AI agents and API keys
If you connect an AI assistant, we store the grant: which client, what it
was allowed to do, and when it was last used. An agent sees only what its
grant allows. API keys are stored as a hash alongside their name, scopes and
the time they were last used — never the key itself.
When an agent rings an alarm, the alarm records the agent's name, so you can
tell which assistant woke you.
How it travels
Everything is encrypted in transit: the console and the management API over
HTTPS, and the live connection your devices hold over WSS. The trigger
domain serves nothing over plain HTTP. A trigger URL is a credential in
itself, which is why the apps refuse to ring one over http://
rather than put it on the wire in the clear.
What we do not collect
- No analytics or telemetry of any kind, and no crash reporting. There is
no third-party script in the console and no third-party SDK in any app or
extension we ship.
- No advertising identifiers, and no advertising.
- No location data.
- No contacts, calendar, photos, microphone or camera access.
- No browsing history. The browser extension asks for one host permission
— our own server — and injects no content script into any page.
- We do not sell or rent personal information, and we do not share it for
advertising.
Who else sees it
Cloudflare runs the whole service: the application, the
database, the real-time connections and outbound email. Data is processed on
Cloudflare's global network, which means it may be handled outside your
country. Cloudflare acts as our processor and does not use your data for its
own purposes.
That is the entire list. There is no analytics provider, no error-reporting
service, no advertising network, and no data broker.
If you install the Android app from Google Play, Google handles the
distribution and whatever its own policies cover. We receive aggregate,
anonymous install statistics from Play; we do not receive a list of who
installed it.
How long we keep it
| What | How long |
|---|
| Account, devices, chimes, triggers | Until you delete them, or close the account |
| Alarm history and receipts | Until you close the account |
| Captured requests | The last ten per trigger, or until you delete them |
| Last caller address, last refused sender | Overwritten by the next one |
| Undelivered alarms waiting for a device to reconnect | 24 hours, then discarded |
Getting your data out, or deleted
You can close your account yourself, from the console. It
is immediate and it is final: your chimes, triggers and their URLs, devices,
keys, agent grants and alarm history all go with it. Nothing is retained
afterwards except what the law requires us to keep.
You can also delete individual triggers, devices, chimes, keys and captures
at any time, and deleting a trigger is the only way to take back a URL you
have shared — trigger URLs are permanent by design and never expire on their
own.
Depending on where you live you may have rights to access, correct, export
or delete your personal data, and to object to its processing. Write to us
and we will help; most of it you can already do yourself in the console.
App permissions
The Android app asks for these, and each is used for exactly one thing:
| Permission | What it is for |
|---|
| Notifications | Showing the alarm |
| Full-screen intent | Letting a chime marked critical take over the lock screen instead of becoming a banner you sleep through |
| Foreground service, wake lock | Holding the connection open so an alarm arrives in about a second rather than whenever the phone next wakes |
| Ignore battery optimisations | Asked for at runtime, and optional. Without it the phone suspends the connection and alarms arrive late or not at all |
| Do Not Disturb access | Only so a chime you marked critical can ring through it. You grant this yourself |
| Start on boot | Reconnecting after a restart, so a rebooted phone does not stop receiving |
| Vibrate, network state | The chime, and knowing when to reconnect |
None of these is used to collect anything.
Children
Alarm Sender is not directed at children and we do not knowingly collect
personal information from anyone under 13. If you believe a child has
created an account, write to us and we will remove it.
Changes
If this policy changes in a way that affects what we collect or what we do
with it, we will update the date at the top of this page and tell account
holders by email before it takes effect.
Single Breath LLC — privacy@alarmsender.com