Privacy Policy

1. Who we are

Data controller within the meaning of GDPR Art. 4(7):

Philip Youn Wai Leong, trading as Picky Alarm (“we”, “us”, “our”)
Goldpeppingstr. 28
60435 Frankfurt am Main
Germany

For data protection enquiries, write to hello@pickyalarm.com or use the contact form. Full details are in the imprint.

2. Data we collect

We collect the following categories of personal data:

• Account data - email address, display name, and a hashed password when you register.
• Calendar data - if you choose to connect Google Calendar, the names of your calendars and, for the calendars you pick, each upcoming event’s title, start and end time, description, location, reminders and recurrence rule, together with the access tokens Google issues for that connection. This data is processed only to set your alarms. Section 8 sets out exactly what we receive from Google and how it is handled.
• App preferences - volume levels, notification preferences, and display settings stored locally on your device and, if you are signed in, associated with your account on our servers.
• Alarm backup data (optional, opt-in required). If you enable Back up to your account in the app Settings, your alarm configurations (name, time, recurrence schedule and ringtone preference) are stored on our servers and linked to your account. This allows your alarms to be restored if you reinstall the app. Cloud backup is disabled by default and can be turned off at any time; disabling it does not delete already backed-up alarms from our servers, but deleting your account removes all alarm data permanently. With the same switch on, your calendar rules (name, title words, the account and display name of the calendars you chose, trigger times, any alarm a rule made that you then edited by hand, and, for an event on a calendar that gives no event id, the title and start of each event whose alarm you edited or swiped away) and your skipped periods (category, dates and reason) are also stored on our servers and linked to your account, so you can restore them on a new phone. They are kept and deleted in the same way as alarm backup.
• Contact form data - name, email address, and message content you provide when you contact us through this website.
• Records of changes to your data - when an account is edited, deactivated or deleted, we keep a dated record that it happened, who did it, and which fields changed. A record of a deletion holds no values from the account, only a one-way hash of the username, so it can confirm an account was erased without keeping the account. This record deliberately outlives the account it describes; see section 7.
• Technical data - request timestamps, the page requested, and your browser’s user agent, in server logs, kept for security and operational purposes. The access log records no IP address, ours or yours. The separate error log records the requesting address on the lines it writes when a request fails, because the web server writes that field itself and offers no way to leave it out. Those lines are written only when something goes wrong, and they are covered by the same retention and the same processors as everything else in this section.
• Crash reports (optional, consent required, off by default). The first time you open the app, it asks once whether to send crash and alarm-failure reports. If you agree there, or enable “Share crash reports” in the app Settings, anonymised crash data (device model, OS version, app version and a stack trace) is sent to Firebase Crashlytics. A report about an alarm that did not ring also carries the phone’s alarm settings (whether notifications, exact alarms and full-screen alarms are allowed, battery optimisation and background restrictions, power saving, boot count and the reasons the app last stopped) and, if “Auto-attach logs to crash reports” is on, the last 50 lines of the app’s alarm log, which hold alarm ids and times only. No alarm names, calendar data, account data or personally identifiable information is included. You can change your answer at any time in the app under Privacy and diagnostics.
• Single alarm-failure report (optional, asked each time). If crash reporting is off and an alarm did not ring, the app asks whether to send one report about that alarm, and shows what it contains: the alarm settings listed above and the last 50 lines of the alarm log. Agreeing sends that report to Firebase Crashlytics the next time the app starts, and leaves crash reporting off. If the app crashes before then, that crash report goes with it, because Crashlytics sends its stored reports together. Declining sends nothing.
• Subscribed calendar feeds (optional). If you add an .ics feed, the app keeps its address on your phone and sends it to our server each time it reads the feed. The server fetches the feed, keeps the events in memory for 15 minutes keyed by that address, and writes neither to a database. A private feed address works like a password for that calendar.
• Weather location (optional, signed in only). If you turn on weather for the night clock and choose Current location, the app sends your approximate location to our server: latitude and longitude, rounded on your phone to two decimal places, which is about 1 km. If you search for a city instead, the app sends the text you typed. Neither is sent unless you turn weather on, and neither is sent while you are signed out.
• Usage data (optional, consent required). If you enable “Share anonymous usage data” in the app Settings, the app sends Firebase Analytics a count of app sessions and of how you use the alarm features: which kind of alarm you create (one-time, recurring or calendar), how a ring ended (dismissed, snoozed or missed), how late a ring started (under 1 minute, 1 to 5, 5 to 10, or more than 10 minutes) and which part of the app started it, roughly how many alarms you keep (1, 2 to 5, 6 to 20, or more than 20), and on which days you used the holiday skip, the night clock or its weather strip. Each of these is a fixed category. No alarm names, times, calendar titles or ringtone names are sent, and no account data or personally identifiable information is included.

3. How we use your data

• Providing the service (legal basis: contract) - account management, authentication, and delivering alarm functionality based on your calendar.
• Weather on the night clock (legal basis: contract) - your rounded location, or the city you searched for, is used to fetch the hourly forecast for your working hours, and for nothing else.
• Responding to enquiries (legal basis: legitimate interest) - replying to messages submitted via our contact form.
• Security and fraud prevention (legal basis: legitimate interest) - detecting and investigating abuse or unauthorised access.
• Legal compliance (legal basis: legal obligation) - retaining records where required by applicable law.

4. Data sharing

We do not sell your personal data. We share data only in the following circumstances:

• Google LLC - calendar data is fetched via Google’s APIs under the OAuth 2.0 authorisation you grant explicitly in the app. Governed by Google’s Privacy Policy. Picky Alarm’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
• Firebase (Google LLC) - used for the following purposes, all governed by Firebase’s Privacy Policy:
  • Firebase Cloud Messaging. When you are signed in, your device token is registered with our server, so it can send push notifications when a linked Google Calendar changes. Without a linked calendar nothing is sent to it.
  • Firebase Crashlytics (consent-based). If you opt in, anonymised crash reports are transmitted to Google’s servers, which may be located outside the EEA. Google LLC participates in the EU–US Data Privacy Framework and provides Standard Contractual Clauses.
  • Firebase Analytics (consent-based). If you opt in, anonymised usage events are transmitted under the same transfer safeguards as above.
  You can withdraw consent at any time in the app Settings under Privacy.
• Bright Sky (brightsky.dev, an open-source service run by an independent developer, hosted in Germany) - if you use weather, our server sends it the rounded coordinates, and it answers with the forecast for the nearest station of Deutscher Wetterdienst (DWD) if one is within 25 km. The request comes from our server, never from your phone, and carries no account identifier. Based on data from Deutscher Wetterdienst, licensed under CC BY 4.0; we convert its weather symbols to the app’s own.
• MET Norway (the Norwegian Meteorological Institute, Norway) - if you use weather and no DWD station is near you, or Bright Sky does not answer, our server sends it the rounded coordinates to fetch the forecast. The request comes from our server, never from your phone, and carries no account identifier. Forecast data is from MET Norway, licensed under CC BY 4.0.
• OpenStreetMap Foundation (United Kingdom) - if you use weather, our server sends its Nominatim service either the text of a city search, or the rounded coordinates of your current location to find the name of the place. As above, the request comes from our server and carries no account identifier. Governed by the OSMF Privacy Policy.
• IONOS SE - our hosting provider, based in Germany (EU), processes data on our behalf as a data processor under a Data Processing Agreement. Your data is stored and processed within the European Economic Area.
• Grafana Labs - our monitoring provider, processing server logs and performance measurements on our behalf as a data processor under a Data Processing Agreement. We use a Grafana Cloud instance hosted in Germany, so this data is stored and processed within the European Economic Area. It exists so we can tell when the service is broken or slow. Its measurements carry no account data: we do not label a measurement with a user id, an email address or any other identifier. The server logs it receives record the address of each request, which for a calendar request can contain a calendar id, and the id of your main Google calendar is your email address (section 8). We count some requests per country, using the country Cloudflare derives from your IP address. We do not store the IP address.
• Legal authorities - where required by law or valid legal process.

5. Third-party services on this website

• hCaptcha (Intuition Machines, Inc., United States) - our contact form uses hCaptcha to tell people from bots. The legal basis is our legitimate interest in preventing automated abuse of a form that sends us mail.
  • When it loads. Nothing is requested from hCaptcha when you open the page. The script is fetched only when you put the cursor in the contact form, so simply reading this site contacts them not at all.
  • Transfer. Loading the widget transmits your IP address and interaction data to Intuition Machines, Inc. in the United States. The transfer rests on the EU–US Data Privacy Framework, and on the EU and UK Standard Contractual Clauses in hCaptcha’s data processing agreement underneath it, which is the same pair of safeguards described for Google in section 4.
  • Processing is governed by hCaptcha’s Privacy Policy.
• Cloudflare Web Analytics (Cloudflare, Inc., United States) - counts page views for this website. The legal basis is our legitimate interest in knowing whether anyone reads the site.
  • What it stores on your device. Nothing. It sets no cookie, writes nothing to local storage, and does not fingerprint your browser, so it needs no consent under § 25(2) TDDDG. There is no identifier that follows you between visits or between sites, and no profile is built.
  • What it sends. The address of the page, the address you arrived from, your browser and operating system version, your country, and the loading timings the browser has already measured.
  • Transfer. Cloudflare, Inc. is in the United States. Cloudflare already serves every byte of this site, so your IP address reaches them on every request whether or not this counter exists. The transfer rests on the EU–US Data Privacy Framework and on the Standard Contractual Clauses in Cloudflare’s data processing addendum, which is the same pair of safeguards described for Google in section 4.
  • Processing is governed by Cloudflare’s Privacy Policy.

6. Cookies and analytics

This website sets no cookies of its own. It is static files served from disk, with no session and no login. We use no advertising cookies and no tracking pixels.

Page views are counted by Cloudflare Web Analytics, described in section 5. It sets no cookie and stores nothing on your device, which is why this site shows no consent banner. Google Analytics is not used here, and neither is a tag manager.

Our CDN, Cloudflare, sets a single strictly necessary cookie, __cf_bm, to tell human visitors from bots. It carries no advertising or profiling purpose and requires no consent under § 25(2) TDDDG.

The mobile app may collect anonymised usage and crash data via Firebase Analytics and Firebase Crashlytics only if you explicitly opt in through the app Settings. No analytics are collected by default.

hCaptcha sets one cookie, and only once you have put the cursor in the contact form: __cf_bm, under hcaptcha.com. It is Cloudflare’s bot-management cookie, the same kind and the same name as the one described above, it carries no advertising or profiling purpose, and it requires no consent under § 25(2) TDDDG. Measured on 4 September 2026 against this page: no cookie of any kind is set before that first click. Apart from the counter named in section 5, no other third party is contacted by this website.

7. Data retention

• Account data - retained until you delete your account. Deletion removes your profile and associated data within 30 days.
• Calendar data - event details are fetched on demand and not stored. For an event you have linked to an alarm we keep its title and start time, so the app can tell you what changed; that record is deleted as soon as you delete the alarm it belongs to, when you disconnect Google Calendar, and with your account. The Google tokens are kept until you disconnect Google Calendar in the app or delete your account; see section 8.
• Alarm backup data - retained for as long as your account is active, and deleted with the account. Deleting a single alarm in the app marks it deleted at once, so it stops syncing to your other devices, and the record is erased within 30 days. The delay is what lets a device that has been offline learn the alarm is gone rather than restore it.
• Weather data - our server keeps a forecast, from either provider, in memory for 30 minutes, and a city search result or a place name for a coordinate for 30 days, keyed by the rounded coordinates or the search text, with no account attached. None of it is written to a database. Your phone keeps the city you chose, or the rounded coordinates it last used and the place name resolved for them, and the last forecast until the next one replaces it.
• Contact form data - your message is sent to us as email and is not stored in the app’s database. We keep the correspondence for up to 12 months and then delete it.
• Records of changes to your data - an edit is kept for 12 months. A deletion is kept for 6 years, which matches the period in which a claim that we mishandled a request could still be brought. The deletion record contains no personal data beyond the hash described in section 2.
• Server logs - two copies, with two limits. On our own server they are capped in size and rotated daily, keeping 14 days. A copy is sent to Grafana Cloud in Germany, described in section 4, and is deleted there after 14 days. The access log contains no IP address; see the note on the error log in section 2.

You can delete your account from the app, or ask us to delete it without installing the app. Both routes, and what each figure above means in practice, are set out on deleting your account.

8. Google user data

This section covers what Picky Alarm receives from Google when you connect Google Calendar in the app. The app asks Google for two read-only permissions and nothing more: calendar.calendarlist.readonly and calendar.events.readonly. We never create, change or delete anything in your Google account.

• What we access. The list of calendars on your account, with each calendar’s id, name, description and colour, whether it is your main calendar, and whether you can only read it or also edit it. For the calendars you choose, upcoming events with their title, start and end time, description, location, reminders, recurrence rule and version tag. Google also issues an access token and a refresh token, which let our server make these read requests on your behalf.
• How we use it. To show you your calendars and events, so you can pick one, and to set an alarm from the event you picked. Its title becomes the alarm’s label, its start time and reminders decide when it rings, and its recurrence rule repeats it. For an event you have linked to an alarm, our server checks the event about once an hour and sends a notification to your phone if its title or start time has changed, so you can move the alarm. Google user data is used for nothing else.
• Who we share it with. No one, except where delivering this feature requires it. The notification about a changed event carries the event’s title and new start time, and it travels through Firebase Cloud Messaging, which is run by Google (section 4). The data is stored on our server at IONOS in Germany, our hosting provider (section 4). Our server logs record the address of each request, and for a calendar request that address contains the calendar’s id and, when you open a single event, the event’s id. The id of your main calendar is your Google email address. Those logs are copied to Grafana Cloud in Germany, our monitoring provider (section 4), and are deleted after 14 days (section 7). We do not sell Google user data. We do not use it for advertising, and we do not pass it to advertisers, data brokers or anyone other than the providers named here. We derive no aggregated or anonymised data from it.
• AI and machine learning. We do not use Google user data to develop, improve or train AI or machine learning models, and we do not send it to any AI service.
• How we protect it. Traffic between the app, our server and Google is encrypted with TLS 1.2 or 1.3. The database runs on our own server, is not reachable from the internet, and only we have access to it. The Google tokens are used only by our server and are never sent to the app or to anyone else. They are encrypted in our database with AES-256-GCM, under a key kept outside the database, so a copy of the database or a backup does not contain usable tokens.
• How long we keep it. Event details are read when you look at them and are not stored, except the title and start time of an event you linked to an alarm (section 7). The Google tokens are kept while Google Calendar is connected. When you disconnect it in the app (Account, Google Calendar, Disconnect), our server asks Google to revoke the access, then deletes the tokens and the records of events linked to your alarms. If you connect again, the app links those alarms to their events again. The tokens are deleted even if Google does not answer, and deleting your account deletes them too. You can also withdraw our access at any time at myaccount.google.com/connections, and the stored tokens stop working at once. To have everything deleted, delete your account.
• Limited Use. Picky Alarm’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

9. Your rights (GDPR)

If you are in the European Economic Area or the United Kingdom, you have the following rights:

• Right of access (Art. 15) - request a copy of the personal data we hold about you.
• Right to rectification (Art. 16) - ask us to correct inaccurate or incomplete data.
• Right to erasure (Art. 17) - request deletion of your personal data where there is no overriding legal basis for retention. Your account and its contents are removed. A dated record that the deletion happened is kept, without your name or any account contents, because Art. 5(2) requires us to be able to demonstrate that we handled the request properly.
• Right to restriction (Art. 18) - request that we limit how we process your data in certain circumstances.
• Right to data portability (Art. 20) - receive your data in a structured, machine-readable format.
• Right to object (Art. 21) - object to processing based on legitimate interests.
• Right to withdraw consent - where processing is based on consent, you may withdraw it at any time.

To exercise any of these rights, write to hello@pickyalarm.com or use the contact form (indicate “Data Request” in your message). We will respond within 30 days as required by GDPR Art. 12.

You also have the right to lodge a complaint with a supervisory authority. Ours is Der Hessische Beauftragte für Datenschutz und Informationsfreiheit, Gustav-Stresemann-Ring 1, 65189 Wiesbaden, Germany. You may instead complain to the authority for the country where you live or work.

10. Children’s privacy

Picky Alarm is not directed at children under the age of 16. We do not knowingly collect personal data from children. If you believe a child has provided us with personal data, please contact us and we will delete it promptly.

11. Changes to this policy

We may update this Privacy Policy from time to time. Material changes will be communicated via the app or by email. Continued use of the service after changes constitutes acceptance of the revised policy.