Privacy

Last updated 5 October 2026

Rooster reads a few things about your day so it can write and record a spoken morning briefing for you. This page says exactly what those things are, where they go, and how to turn any of them off.

Rooster is made by Tropical Labs Ltd, a company registered in England and Wales (number 17339629), with its registered office at Flat 1, 25 Oakhurst Grove, London SE22 9AH, United Kingdom. Tropical Labs Ltd is the data controller for the information described here, and you can reach us at hi@rooster.am.

The short version

• There is no account. Rooster does not ask for your email address, a password, or a social login.
• We never sell your data, and we never use it for advertising or share it with advertisers or data brokers.
• Everything Rooster reads about your day is read-only. It is used to write that morning’s briefing, and nothing is written back to your calendar, your reminders, or anywhere else.
• Every source is optional. Decline any permission and Rooster simply leaves that part out of your briefing.

No account, no sign-up

Rooster signs your device in anonymously. That gives your phone an identifier so your alarms and briefings can be generated and delivered back to the right device — it is not linked to your name, email address, or any other identity, and we cannot use it to contact you.

If you tell Rooster your first name during setup, it is stored with that anonymous identifier and used for one thing: so the briefing can greet you. You can leave it blank.

What Rooster collects, and why

Briefings are written and recorded on our servers overnight, so the audio is on your phone before the alarm rings and no morning depends on a working network. That means the material below is sent to our servers at the time it is needed.

Calendar and reminders

Rooster reads calendar events and reminders read-only, and only for the day the briefing covers. It never creates, edits, or deletes anything in your calendar or reminders, and it does not read your history.

If you connect a Google account, Rooster requests a single scope, calendar.events.readonly, and nothing more.

For events with other guests, Rooster reads the guest list to work out who the meeting is with. From it we take first names (at most three per event, and none at all for invites of more than six people), how many other people are invited, who organised it, your own reply, and whether anyone has an email address outside your organisation’s domain. Email addresses and surnames are only used to work those out. They are never stored and never sent to anyone. Events you’ve declined are left out of your briefing.

Rooster’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. The use of raw or derived user data received from Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements. Google calendar data is used solely to generate your morning briefing. It is not sold, not shared with third parties for their own purposes, not used for advertising, and not read by our staff except where you have asked us to help with a support issue, or where we are required to by law.

You can disconnect at any time in the app under Settings → What’s connected, or revoke access from your Google account’s permissions page. Disconnecting deletes the stored authorisation.

Other people on your invites

The people on your invites haven’t signed up to Rooster, so we use as little about them as we can. Their first names and the headcount are used only while your briefing is being written and are then discarded. They aren’t saved with your briefing, the app never receives them, and they’re never written to our logs or crash reports. If your briefing mentions someone by first name (“a catch-up with Priya at half past nine”), that sentence is part of your briefing. It’s kept with the rest of your briefings and deleted with them.

Who processes this, and where

Writing and recording a briefing needs a handful of services. They act on our instructions, and they receive only what that job needs.

News comes from public sources — publishers’ own feeds and public news listings. Reading them does not send anything about you to those publishers.

AI services, and what they may not do with your data

Several of the services above are AI models. This is exactly what each one sees, and what none of them is allowed to do with it.

• Anthropic (Claude), via the Anthropic API.Writes the briefing script. It receives the material a briefing is written from: your first name, the day’s calendar events (titles and times, and for Google Calendar events, the first names and headcounts described above), reminders, forecast, city, and news headlines. Anthropic’s commercial terms prohibit it from training models on this content, and it is retained only briefly for abuse monitoring, never for training.
• MiniMax speech models, run through Replicate.Turns the finished script into the recorded voice. It receives the script text only — which may name an event, or a first name from your calendar, since the briefing does — and never the calendar itself. Predictions made through Replicate’s API are deleted from Replicate after one hour.
• Google Gemini speech models, via the paid Gemini API. Records the voice for the voices that use it. It receives the same script text as above and nothing else. Under Google’s terms for the paid API, it is not used to train or improve Google’s models, and is kept only for a limited time to detect abuse.
• Image models, run through Replicate. Paint the cover art for a morning. They receive a style description we write ourselves and nothing about you: no events, no location, no name.

None of these services is permitted to use your data to train, improve or evaluate their own models, and we do not use your data, in raw or derived form, to train any model of ours. Google calendar data in particular is used to write your briefing and for nothing else; it is never used to build, train or improve any machine-learning or AI model, ours or anyone else’s. We only use these providers under agreements that carry these restrictions, and we would tell you here before adding one that does not.

Payments

Subscriptions are purchased and billed by Apple through the App Store. We never see or handle your card details. We receive only whether a subscription is active.

Our legal basis for using it

Under UK data protection law we have to tell you why we’re allowed to use your information. There are three reasons here:

• To do what you asked us to. Your alarms, settings, calendar, reminders, location and weather are used to produce the briefing you signed up for. Without them there is no product to deliver.
• Our legitimate interests. Crash reports and the small set of app events keep Rooster working and tell us whether it is worth continuing. We keep both deliberately thin, and neither is used to profile you or to advertise to you.
• Legitimate interests, for other people on your invites.Saying who a meeting is with makes your own briefing more useful. We use only first names and counts, we don’t keep them, and we use them for nothing else.

Where in the world it goes

Rooster is run from the United Kingdom, but the services that store data and generate briefings are based in the United States — Supabase, Render, Anthropic, Replicate, Google and Sentry, as listed above. That means your information is transferred outside the UK. We rely on the UK Government’s adequacy regulations where they apply, and on the UK International Data Transfer Agreement or Addendum where they don’t.

How we protect it

• Encrypted in transit and at rest. Everything between the app, our servers and the services above travels over TLS. The database and audio storage are encrypted at rest by Supabase.
• Google authorisations are encrypted separately. The token that lets Rooster read your Google Calendar is encrypted with a key that is not stored in the database, so a copy of the database alone cannot read it. The Google access token itself is never stored and never leaves our servers; the app on your phone never sees it.
• Least privilege, throughout. Rooster asks Google for one read-only scope. The app on your phone cannot read the database directly: every table is locked to server-side access only. Our servers hold credentials for exactly the services they use.
• Staff access is the exception, not the rule. Nobody reads your briefings, events or settings in the course of running Rooster. Access happens only to resolve a support request you have made, or where the law requires it.
• Deletion is real. Deleting your data removes every row and every recording, and destroys the anonymous identity, so nothing can be re-linked afterwards. Disconnecting Google Calendar deletes the stored authorisation immediately.
• If something goes wrong.If we discover a breach that affects your data, we will notify the Information Commissioner’s Office within 72 hours where the law requires it, and tell affected users through the app without undue delay.

How long we keep it

We keep it for as long as you use Rooster.Your settings, alarms, briefings and the recordings themselves stay put so you can go back and listen to recent mornings, and so tomorrow’s briefing knows what yesterday’s said. The material a briefing was written from — your events, reminders, weather and location for that day — is kept with that briefing.

Two things end that, and both are automatic:

• You ask us to. Deleting your data in the app removes all of it, immediately — see below.
• You stop using Rooster. After a year with no sign of the app on any device, we delete everything without being asked. Nothing is kept indefinitely for someone who has gone.

Spending stops long before that: we only write briefings for devices seen in the last couple of weeks, so a deleted app stops producing new mornings almost immediately.

Your rights

UK data protection law gives you the right to ask us for a copy of what we hold about you, to have it corrected, to have it deleted, to restrict or object to how we use it, and to receive it in a portable form. Email hi@rooster.am and we will act on it.

One honest caveat: because Rooster has no accounts, we identify you only by the anonymous identifier on your device. To act on a request we need that identifier, which the app can show you — without it we genuinely cannot find your data, which is a consequence of collecting so little of it in the first place.

If you think we’ve got this wrong, you can complain to the Information Commissioner’s Office at ico.org.uk. We’d rather you told us first, so we can fix it.

Your controls

• Turn any source off. In the app, Settings → What’s connected shows every permission Rooster uses, what it adds, and how to switch it off. iOS Settings can revoke any of them at any time.
• Disconnect Google Calendar from the same screen.
• Delete everything, yourself. Settings → Delete my data in the app erases the lot: your alarms are cancelled, every briefing and recording is deleted from our servers, and the anonymous identity your device was using is destroyed. Rooster starts again as if you had just installed it. There is no undo — not by you, and not by us.
• Or ask us. Email hi@rooster.amand we’ll do it by hand. Deleting the app stops any further collection, but on its own it doesn’t delete what we already hold — use one of the two routes above for that.

Children

Rooster is not directed at children under 13, and we do not knowingly collect their information.

Changes

If this page changes in a way that matters, we will update the date at the top and say so in the app.

Contact

Questions, or a request to delete your data: hi@rooster.am.