01 What the app stores
Until every phone runs version 1.1, our server also does what this page described on 17 October 2026: it counts snoozes, counts stopped-alarm messages from test versions, sends an iPhone a check that its final wake is still set, and keeps the earlier final-wake note; all of it labelled with the environment only, never an account.
To make the alarm work, the app stores the following on our server (a Cloudflare Worker) and on your device:
| Data | Why | Where |
|---|---|---|
| Your account id | A one-way hash of the identifier your phone’s sign-in service gives us — Sign in with Apple on an iPhone, Google on an Android phone (below). Ties your alarm, webhook and subscription to you and lets your account follow you to a new phone. It is not your name or email, and it cannot be turned back into your Apple Account or Google account. | Device + server |
| Alarm settings | Your wake window, the days it repeats on, timezone, label, and on/off state — and an internal marker of when the alarm was last saved or started again, an internal alarm id, and, when you end a wake or skip a day, that day’s date (so no early wake is sent that day). None of these says anything about you. | Device + server |
| A Sign in with Apple token (iPhone) | Kept only so that deleting your account can tell Apple to disconnect the app from your Apple Account. Never sent to your phone, never used for anything else. | Server |
| Personal webhook secret | Lets your platform's alert reach the app. Treat it like a password. | Device + server |
| A push token (Apple’s on an iPhone, Google’s on an Android phone) | Delivers an early-wake push to this device. With it we keep one number: which version of the app’s connection to our server this phone last used, so a push can be sent in a form the phone reads. It is the same for everyone on the same version of the app and says nothing about you; it is replaced each time the phone registers, and removed with the token and with your account. With it we also keep two things this phone tells us: which alarm tone you chose, so an early wake can ring it, and whether the phone’s Alarms permission is on, so we send nothing to a phone that cannot ring. Each is replaced when the phone next reports it; both stay if the push token is dropped or your sign-in lapses, and are removed with your account. | Server |
| The text of your latest alert | Shown in the app as what moved, and why it did or didn't wake you. Only your most recent alert is kept — replaced by the next one, and deleted with your alarm or your account. With each early wake we also keep whether your phone said its alarm started, and, when it did not say so in time, how many follow-up pushes we sent and why they stopped, and a sealed code its pushes carry, which only our server can open, so our server knows whether to send another; which push service (Apple’s or Google’s) its push was last handed to, when that service first and last accepted it or the reason it gave for refusing it, and when the next push is due — shown back only to your own app, for the recap; replaced by the next alert's record and deleted with your alarm or your account. The alert that woke you is also kept on your phone, in the record of your last alarm, so the recap can show it again later — until your next alarm's record replaces it. It is also removed when you save a change to your alarm or delete it, when you choose Wake Me Again Today, when you sign out or sign in, and with your account. It never goes to analytics. | Server; the alert that woke you, also on your device |
| The times and outcomes of up to eight of the day's alerts that did not wake you | Kept for the recap, so it can say whether an alert arrived during your wake window and what became of it. Only alerts that arrived inside the window, at most one a minute — the time and what became of each, never the text. Replaced by the next day's first such alert, and deleted with your alarm, a regenerated webhook URL, or your account. The one the recap describes is also kept on your phone, in the record of your last alarm. It never goes to analytics. | Server; the one the recap describes, also on your device |
| Whether your iPhone has said the morning of your last final wake is over | Kept only so that, if it has not, our server can send this iPhone one quiet notification about three hours after that final wake (described below). When a final wake comes due on a day your iPhone has not already marked as over, our server notes that final wake’s time and day; when it sends the notification it notes when it last tried, and whether it is done. It decides nothing about your alarm, and none of it is sent to your phone: the notification carries fixed words. Replaced the next time a final wake comes due that way. Once the morning has ended and half an hour has passed since that final wake, the note is deleted the next time our server handles your alarm: when a change to it is saved, or at your next final wake, when the next note takes its place; it is also deleted with your alarm, when your sign-in has lapsed, when you next sign in, when your account moves to an Android phone, and with your account. Not kept for an Android phone. | Server |
| How many alerts reached us each day, and whether the account was active that day | Counted, never read, so we can see how many accounts are in use and how heavy the traffic is — with the account's subscription state (paying, in a free trial, or not subscribed). Filed under a key derived one-way from your account, which we use only to find an account whose alerts arrive far faster than a wake needs, kept for up to six weeks, then deleted. Only numbers and that state — no alert text, no times. | Server |
On an iPhone, when you stop an early or final wake’s system alarm, the app notes on the phone which alarm it was and the time you stopped it, so it knows that morning was answered even if the app was not open. These notes never leave the phone and say nothing about your account. The app removes a note once it has recorded it, keeps no more than eight, and clears them when you start your alarm over, when your account is deleted, and when this phone signs out for any reason other than an expired session.
Also on an iPhone, each time an early-wake push reaches the phone, the part of the app that receives it writes one line on the phone: the time of the early wake it was for, when our server sent the push, when it arrived, when that part of the app finished with it, one word for what it did (for example, that it started the alarm), which kind of push it was (an early wake or a follow-up), that morning’s final wake time, whether it removed that final wake, how many of our other alarms it stopped, and whether it told our server the alarm had started — never the code a push carries — and the app’s build number. Never the alert’s text, and nothing about your account. The app reads these lines so that it knows an early wake rang on this phone even when it cannot reach our server, and to measure how long pushes take (sent only as the two durations described under Product analytics, never the times themselves). No more than twenty are kept; a line older than 48 hours is removed only the next time a push arrives, and all of them are cleared when this phone signs out for any reason other than an expired session, and when your account is deleted.
On an iPhone, so that an early wake you answer before the phone is first unlocked after a restart is not forgotten, and followed by the final wake, the notes above are kept in one file the phone can read then: which alarm you stopped and when, the lines about each early-wake push, which alarms you answered (on the alarm or in the app) and when, and the time you last started your alarm over, with the internal marker of which start of your alarm this is. That file holds nothing you typed and nothing an alert carried, and nothing about your account; it never leaves the phone and is not in the phone’s backups. Everything else the app keeps on an iPhone, your webhook address and your latest alert’s text among it, can be read only after the phone has been unlocked once since it started.
On an iPhone whose morning our server did not hear was over, about three hours after the final wake our server sends one quiet notification, with no sound and with fixed words that say nothing about you or your alarm. The part of the app that receives it looks at the alarms the phone holds and writes over those words the time of your next final wake, or, if the phone holds none, that no final wake is set, with a sound. That line is written on the phone, from the phone’s own alarms, and is sent nowhere. If your notification previews are on, it can be read on your Lock Screen. The app does not show it while it is open on your screen.
On an Android phone, so that its alarms ring even before the phone is first unlocked after a restart, the app keeps your final wake times, their time zone and the tone in storage the phone can read then, and beside them a few notes from the alarm itself: whether you answered an early wake with I’m Up or Snooze and when, that you tapped I’m Up on a final wake and when, until when early-wake pushes should be let go unrung, and — when you snooze an early wake on its alarm — when it is to ring again and when you tapped Snooze. An early wake can also ring then: its push carries no words, so the alarm says only “Early wake”, and the alert’s text is shown in the app once you open it. Nothing more is kept for it. It also notes, when an early wake rings, which early wake it was (the moment its alert reached us), when it first and last began ringing, and, if it took the place of that day’s final wake, that final wake’s time; no more than twenty, a line older than two days removed the next time an early wake rings, and all of them cleared when your account is deleted and when this phone signs out for any reason other than an expired session. Those notes from the alarm never leave the phone and hold nothing you typed and nothing an alert carried (your wake times and tone are your alarm’s, kept on our server as the table above says). A final wake’s time goes once it rings or is replaced, the snooze once it rings, and your answers once the app next reads them, even after a sign-out. The snooze, its tap time and the hold on pushes are also cleared when you start your alarm over, when your account is deleted, and when this phone signs out for any reason other than an expired session. On Android an early wake’s alarm, on the alarm screen and on the Lock Screen, says “Early wake” and never shows the alert’s text.
We never keep your name, email address, or contacts. Creating your first alarm signs you in with your phone’s own sign-in service. On an iPhone that is Sign in with Apple, and we request no scopes: no name and no email, so we are never given either. On an Android phone it is Google, which always includes your name and email in what it sends at sign-in — there is no way to ask it not to. Our server reads only the identifier from it, in that one request, and keeps neither your name nor your email. The identifier is what we use: we one-way hash it into an account id, which cannot be turned back into the account you signed in with.
02 Product analytics and crash reports
We collect app analytics only to improve the app's functionality, reliability and usability. That is the sole purpose.
Collected
- ✓ Which screens you open
- ✓ Which controls you tap
- ✓ How a wake cycle turned out
- ✓ That you created an alarm (how long its wake window is in minutes and how many days it repeats — never its times) or changed one (only whether the window, the days or the timezone changed), whether you allowed a permission the app asked for (which one, and yes or no), how your first setup ended (whether Alarms was allowed, whether you picked your own days, and how you connected your platform: with a setup link, by copying the webhook, through the share sheet, or not yet), that the app on this phone first saw one of your alerts, which alarm tone you picked, how long a Nightstand session lasted in broad bands and whether a wake or you ended it, that a wake went in a way the app did not expect (which two stages of the wake it moved between, from a fixed list — never a time), the version of the app’s connection to our server and that our server turned it away (in which of two ways), why a purchase could not finish (one word from a fixed list), and which stage of the app sent the event (development, TestFlight test or store version)
- ✓ That a step of a wake did not finish on the phone (which step, from a fixed list — never a time, an alarm or an error’s text)
- ✓ That a launch reached one of its steps on the way to the first screen (one word of a closed list of eight: the launch begun, the app’s local id read (it stays on the phone), the sign-in checked (with Apple, on an iPhone), our server asked for your status, asked once more, and answered, your alarm set, the phone’s alarms read — one entry for each step reached; never your alarm’s settings, a time you set or anything you wrote)
- ✓ Whether a setup link you asked for was opened
- ✓ That a screen found no network connection, or could not reach our service (which screen, which of the two, and whether the app showed your saved alarm instead)
- ✓ That the app could not read one of the phone settings a wake depends on (which one: Time Sensitive Notifications or Alarms)
- ✓ That the app could not read the phone’s saved sign-in when it started, and waited until it could (whether the phone said it was locked, whether an early wake’s stop started the app, whether an alarm was saved on the phone, how long the wait was in broad bands, what ended it — the phone being unlocked, the app coming to the front, or the app’s own next try — and whether a sign-in was then found, the app gave up and asked you to sign in again, or the saved sign-in was missing on a phone that had signed in, and whether the app had first been waiting) — and that the saved sign-in was moved to where a locked phone can read it: sent once when the move is made, or at each launch while it could not be. Never the sign-in itself, or anything about the account
- ✓ That a sign-in was declined, by Google on Android or by our server on either phone (only which of the two — never which account)
- ✓ That our server refused an alarm the app sent (which action sent it, the status code, and the alarm’s shape: on or off, how many days, the wake window’s length in broad bands, whether its timezone is the phone’s own, whether a day was set aside — never its name, its wake times or which timezone)
- ✓ On an iPhone, how long an early wake’s notification took to arrive and whether it rang as an alarm (two durations and one word — never the alert)
- ✓ That you saw the price, started a trial, subscribed or renewed, or your subscription ended (only how the app learned of it — never an amount or a receipt)
- ✓ That you deleted your account (the fact, nothing about who)
- ✓ What the app and phone are, sent with every event: the app’s name, identifier, version and build; the analytics library’s version; the phone’s operating system and version, manufacturer, model and type (the hardware’s model, such as “iPhone 16 Pro” — never the name you gave the phone); its screen size; that it is a real phone and not an emulator (an emulator sends nothing); and a random session id. Never your timezone, language setting or a place worked out from your address
- ✓ Crash diagnostics
- ✓ From our server: how many alerts arrived inside your wake window and what became of them (once per kind per day), a daily count of alerts in broad bands with whether the account is subscribed, whether a wake push was accepted by the push service (Apple’s or Google’s), on a morning an iPhone did not tell it in time that its early wake’s alarm had started, how many follow-up pushes it sent, in broad bands, and why they stopped (the phone said the alarm had started, the phone said the morning was over, the alarm was changed, or fifteen minutes passed after Apple first accepted the early wake), how many mornings it heard ended, and by which wake (dated only by the day, in UTC), how often it sent an iPhone the quiet notification about three hours after a final wake the phone had not said was over, and what the push service answered (dated only by the day, in UTC, on which it was sent), how often it refused an alarm an app sent and which of its rules the alarm broke (with the shape of what broke them: whether its on/off setting was a yes or no, whether a time was missing or malformed, the wake window’s length in broad bands, how many days it listed and whether any was out of range or repeated, how long the timezone’s name was and whether it had a “/”, whether the internal marker of when it was last saved was well formed, whether a day was set aside, and the version of the app’s connection to our server — never the alarm’s name, a wake time or the timezone itself), how often it turned away an app that named no version of its connection to our server, or one it does not speak (which of the two, and nothing more), and whether a subscription record changed or a purchase receipt was refused, and whether a sign-in kept the Sign in with Apple token and an account deletion could revoke it, how often it declined a sign-in, with which service it was (Apple or Google) and why, in one word from a fixed list (it could not get Apple’s or Google’s keys, the sign-in named a key they do not list, something on our side failed or was not set up, the sign-in was not one they signed, had expired, was not issued by them for this app or named no account, was not this sign-in’s, or the request was incomplete or of a kind this server does not take) — never the sign-in itself, whether a wake happened only because a test purchase's extended access was still open (a tester's, never a paying customer's), how often an account came to rest because no phone was signed in to it, was woken by a sign-in, or was deleted after twelve months at rest (each a bare count), and how often our server met an error of its own (whether in answering a request, in a scheduled task or in an account’s alarm; for a request, only the first word of its address, from a fixed list; and the error’s type, from a fixed list — never its message or the rest of the address) — labelled only with the environment, never with an account
Analytics never receives
- ✕ Your alert text
- ✕ Your webhook URL
- ✕ Your account id
- ✕ Your IP address
- ✕ Your timezone or locale
- ✕ Your wake times as a value of their own (each event carries the moment it happened)
Excluded in the app's code, not merely by policy.
Not linked to you. Events are grouped by a random identifier created on your device (a device-level identifier, in Apple’s terms). It is not your account, it is never linked to you, and we keep no record connecting it to anyone. No profile of you is built.
Purchases. The subscription is sold and billed by your phone’s app store — Apple’s App Store on an iPhone, Google Play on an Android phone. When you subscribe, the store sends our server a transaction identifier, the product, its dates and its status — never your name, card or address — and sends updates when it renews, lapses or is refunded. On Android our server asks Google Play for that record itself, using the purchase’s token (we keep only a one-way hash of the token), and tells Google Play the purchase was received. That record is kept on your account so the app knows whether early wakes are on, and it is deleted with the account. It is separate from analytics and is not sent to PostHog.
03 What we don't do
- No advertising or ad networks.
- No tracking across other apps or websites.
- No sale or sharing of personal data with data brokers.
- We do not monetise your data or your usage in any way. The subscription, sold through your phone’s app store, is how the app is paid for.
04 Third parties
05 Retention & deletion
Your alarm settings persist while your alarm exists. Deleting the alarm in the app removes its configuration from our server. Regenerating your webhook URL immediately invalidates the old one.
When you stop using the app. Your account stays exactly as it is while any phone is signed in to it. A sign-in lasts 30 days. In its last week it is renewed for another 30 whenever the app, still signed in, reaches our server. Opening the app does that. Stopping an alarm without opening the app may too: the phone can then run the app briefly in the background, where it makes the same requests it makes when opened and nothing more. Whether it runs is the phone’s decision, so it is not something to count on. When no phone is signed in any longer, your account rests: no early wakes are sent, and alerts are noted but ring nothing. Signing in again brings it all back unchanged, webhook URL included. If it stays that way for 12 months, we delete the account and everything on it, exactly as Delete Account & All Data would — including the Apple disconnect below. While a subscription is still running, the 12 months start when it ends.
Apple’s email after you delete your account. Deleting your account also tells Apple to disconnect the app from your Apple Account, and Apple emails you to say so. Its line about sharing your name and email “again” is Apple’s standard wording for every app: we never asked for either, and signing in again will not ask for them.
Analytics and crash data are separate, because they are not linked to you. They carry no account id and nothing else that identifies a person, so there is no “your analytics” for us to look up. Deleting your account removes your account, alarm and webhook, and the record of your subscription on our server, including the link between the store’s transaction and your account. Analytics needs no deletion step: none of it is attached to you, and all of it is deleted automatically after 30 days.
Without the app. An account signed in to with Google (Android) can also be deleted at tradingalarmclock.com/delete-account/google: you sign in with Google there, Google hands the sign-in back to that page, and the page sends it to our server only to find and delete the account — the same deletion as the app’s button. Nothing is collected that the app’s sign-in does not already send, and nothing it sends is kept. The one thing deleting does not remove is the daily alert counts described in the table above: they are filed under a key derived one-way from your account, which we use only to find an account whose alerts arrive far faster than a wake needs, and are deleted automatically within six weeks.
To request full deletion of any account data associated with your account, email us at the address below.
06 Your rights, and where your data is processed
Wherever you live, you can ask us what we hold about you, ask us to correct it, or ask us to delete it — email the address below. Most of it you can delete yourself in the app (Account → Delete Account & All Data). Because we never asked for your name or email, your account is found through your sign-in, not your address — so for a request about the account itself we will help you make it from the app. We answer within 30 days, and we never treat you differently for asking.
We do not sell or share personal information, as those terms are used in California’s privacy law (CCPA/CPRA), and we do not use it for targeted advertising.
Our server runs on Cloudflare’s global network, which stores your account in one of its data centres — possibly outside your country. Analytics are processed by PostHog in the United States. If you use the app from Canada, Australia, New Zealand, Singapore or elsewhere outside the US, your data is processed there, protected as this policy describes.
07 Children
The app is not directed to children and does not knowingly collect data from children under 13.
08 Changes
If this policy changes, the date at the top of this page changes with it. Material changes will be described in the app's release notes.
09 Contact
Deleting your account takes two taps in the app; how, and what is deleted.