01 What the app stores
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, which says nothing 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. 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 phone has said the morning of your last final wake is over | Kept only to be counted, so we can see how often a final wake goes unanswered for hours (the count is described under Product analytics and crash reports). When a final wake comes due on a day your phone has not already marked as over, our server notes that final wake’s time and day, whether an early wake was still unanswered at that moment, and a number that starts at one and goes up by one each time the morning before it was never marked as over. Afterwards it notes two more things: whether the app was in touch with our server more than about three hours later, and that the morning ended — your phone said it was over, or you changed your alarm. It decides nothing about your alarm and is never sent to your phone. The count does not carry the final wake’s time: it is dated only by the day, in UTC, on which it was counted. The count carries the rest of the note only as fixed words and broad bands, with no account. Our analytics provider, PostHog, also records the moment each count reached it, so a count sent when the next final wake comes due shows that final wake’s time, to the second, with no account beside it. 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, and when you next sign in, and with your account. | 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 |
In test versions of the iPhone app (builds from TestFlight), when you stop an early or final wake’s system alarm the app tells our server that an alarm was stopped. The App Store version does not send this. The message is sent with the phone’s sign-in, so the server knows it is the app, and the server keeps nothing from it against your account: it adds one to the count described under Product analytics and crash reports and nothing else. It is sent only to be counted, and the Usage analytics switch does not stop it. On the phone the app keeps one word between stops — how far its last such message got — which is sent with the next one and says nothing about you.
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 read 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 our server’s check that your final wake is still set), 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 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. 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.
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
- ✓ Whether a setup link you asked for was opened
- ✓ That a screen found no network connection, or could not reach our service (which screen, and which of the two)
- ✓ 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 Google declined a sign-in on Android (only that it happened — 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 your subscription ended (bare events — 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, snoozes, how often a phone told it that an alarm had been stopped (which wake, how long after the stop the message left the phone, in broad bands, and how far the phone’s previous message got), whether a wake push was accepted by the push service (Apple’s or Google’s), how often it sent an iPhone a check that its final wake was still set (and whether an early wake had fired that morning), how often a phone had still not said, about three hours after its final wake, that the morning was over (with what ended the wait — the phone saying so, the alarm being changed, or the next final wake coming due — how long that took in broad bands, whether the phone is an iPhone, an Android phone or has no push token, whether it is on the current version of the app’s connection to our server, whether the app had been in touch in the meantime, whether an early wake was still unanswered at that final wake, and whether it was the first, second or a later such morning in a row — fixed words and broad bands only), 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), 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, whether a wake happened only because a test purchase's extended access was still open (a tester's, never a paying customer's), — 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.