Draft, pending legal review

Privacy Policy

Last updated: draft of October 9, 2026.

QueueWatch is run by [LEGAL NAME] ("we" or "us"). It is a web app at [DOMAIN] and an iPhone app. This policy covers both. For questions or requests, email [SUPPORT EMAIL].

The short version

• No accounts. We never ask for your name, email address, phone number or contacts.
• Your exact location stays on your phone. If you allow it, your phone works out which park you are in. We receive a park only if you choose to use it.
• We keep what it takes to send your family's alerts: your trip's code and settings, a token to reach each phone, and a short log of recent alerts.
• No ads, no analytics, no tracking. We don't sell your data or share it for advertising.
• Tokens and trips are deleted. A phone's push token is deleted when you turn alerts off, when the phone leaves the trip, and when the trip is deleted or goes idle. Idle trips are deleted 30 days later.

1. What we keep, and why

1.1 Your trip

A trip is a shared 6-character code, such as K7M2QX, that your family's phones join. For each trip we keep:

• the code, and a random name for its ntfy topic (section 3);
• the park the trip is at, the rides it follows and the rides it has muted, and which rides it followed at other parks;
• pause settings, such as "pause alerts until 3 PM";
• whether crowd alerts and ntfy are on, and when a phone last confirmed that an ntfy test arrived;
• when the trip was made, and when someone last opened it (updated at most once an hour);
• a few internal markers, such as the Home Screen badge count last sent and when an "about to go idle" notice went out.

Why: to know what to alert you about, and when to stop.

The trip code is the key to your trip. Anyone who has it can see the trip, change its settings, see its recent alerts and delete it. Share it only with people you trust.

1.2 Each phone on a trip

When a phone turns on QueueWatch alerts, we keep:

• A phone id. This is a random code we make. It is not your phone's serial number or advertising identifier, and it means nothing outside QueueWatch.
• A push token, so an alert can reach the phone:
  • in the web app, a push address and its keys, issued by your browser's push service (Apple, Google, Mozilla or Microsoft);
  • in the iPhone app, an Apple Push Notification service (APNs) device token, which Apple issues for QueueWatch on that phone, and whether it is for Apple's test or live service.
• Live Activity tokens, in the iPhone app only. When you keep a down ride on your Lock Screen, Apple gives that Live Activity its own token. We keep up to 5 per phone, each with the ride it is for and when it was set, so we can keep the back time on your Lock Screen current.
• The phone's own pause.
• When it joined, when it last signed up again, and when an alert last reached it.

A trip can have up to 20 phones.

1.3 When push tokens are deleted

We delete a phone's push token (its push address and keys, or its APNs token) and its Live Activity tokens:

• when you turn off alerts for that phone in QueueWatch (More, then Alerts on this phone, then Turn off for this phone);
• when you turn off notifications for QueueWatch in your phone's or browser's settings. We learn of it the next time you open QueueWatch, and delete the token then;
• when the phone leaves the trip, or switches to another trip;
• when the trip is deleted;
• when the trip goes idle (section 4);
• when Apple or the push service tells us the token no longer works.

One Live Activity token is also deleted when that Live Activity ends.

After a phone leaves a trip, we keep three things so that it is still paused if it comes back: its phone id, its pause setting, and a one-way scrambled form (a hash) of its old push token, which can't be turned back into the token. We keep at most 20 of these per trip. They are deleted with the trip. Any "Just me" short line alerts the phone set are deleted when it leaves.

Our daily backup copy can keep a deleted token for up to a day (section 4).

1.4 Recent alerts (the push log)

For each trip we keep the last 40 alerts, so "Recent alerts" in the app can show what went out and why:

• the time, and the alert's title, for example "Space Mountain is down";
• whether it went to ntfy, and how many phones it reached;
• how many phones were paused, or why the alert was held;
• whether it was a test or a notice, and how many times a failed send was retried;
• when a Lock Screen Live Activity was ended.

The log doesn't name any phone.

1.5 Short line alerts

When you ask to hear when a ride's wait drops, for example under 30 minutes, we keep:

• the ride, the minute limit, the park day, and when you set it;
• when it went off, and what the wait was then;
• whether it lasts all day.

For a "Just me" alert we also keep your phone id, so only your phone gets it. Other phones on the trip see only a one-way fingerprint of it, enough to show "set on another phone".

Short line alerts last one park day, and are deleted after it.

1.6 Location: used on your phone

QueueWatch can use your location to find which park you are in, if you allow it:

• when you tap to find your park while setting up;
• when you turn on "Switch parks when I arrive";
• when you open QueueWatch at a different park and location is already allowed. QueueWatch then asks whether to move alerts to that park.

Your phone compares its location with each park's area on the phone itself. Your coordinates are never sent to us or to anyone else, and are not stored. Your phone remembers the last park it found you in. In the iPhone app, QueueWatch asks for location only while you are using it, at about 100 meters' accuracy.

If you then start a trip at that park, or move your trip to it, we receive which park, just as if you had picked it from the list. We never receive where you are in it. Because that park came from your location, we count it as approximate location.

QueueWatch never asks for location on its own and never uses it in the background. Without it, you pick the park from a list.

1.7 The app install id

Each copy of QueueWatch makes one random install id the first time it needs one, and keeps it on the phone. It is not tied to your phone's hardware or your Apple ID. We use it only for the free day:

• When QueueWatch opens a trip's pass details, we note the install id with the time, for up to a day. This lets a phone use the trip's free day even with alerts off.
• When a free day is used, we keep which install id (or phone id) used it, and the result of the DeviceCheck test in section 1.9, with the trip's billing record.

1.8 Passes and purchases

Passes are sold by Apple through the App Store. Apple handles payment. We never see your name, Apple ID, email address or card.

When you buy, restore or renew a pass, Apple gives your phone a signed record of the purchase. Your phone passes it to us. We check Apple's signature, keep the facts below, and don't keep the signed record itself.

For each trip:

• a random billing id. Your phone gives it to Apple with each purchase, so Apple's records can be matched to the trip;
• each pass:
  • its type (Day, Trip or Annual);
  • Apple's transaction numbers for it;
  • when it was bought, when it starts and when it ends;
  • whether it was a test purchase, and whether and when it was refunded;
  • the phone id of the phone that bought it, if that phone had alerts on.

For an Annual Pass:

• Apple's original transaction number, and each paid year's number, start, end and any refund;
• the trip it is on, and the phone id of the phone that bought it;
• whether it will renew;
• when it moved between trips (it can move at most 3 times a day).

Also:

• Which purchase is on which trip, so one purchase can't unlock two trips.
• Every purchase number ever used, kept permanently. It is kept on its own, with no trip, phone or date. It only stops the same purchase from being used twice.
• Apple's notices about purchases (renewals, refunds, cancellations). We keep each notice's id and when it arrived, for 30 days, so none is applied twice.
• When the iPhone app last used a trip, one time per trip. While passes are needed only on the iPhone app (the web is free for now), this tells us which trips need one. It is deleted after 30 days, or with the trip.
• App Review's test purchases. During review we accept Apple's test (Sandbox) purchases, mark them as tests, and let each cover one park day at most. We count them per trip for 2 days.

How long:

• Ended passes, and ended Annual Pass years, are deleted 30 days after they end. Only the bare purchase number stays (above).
• If a trip is deleted, its billing record is deleted within an hour. A pass that hasn't started or is still running is kept apart, so you can move it to your next trip with "Restore purchases". It is kept for up to 400 days if it never started, or until 30 days after it would have ended.
• Our daily backup copy of the billing records can keep a deleted record for up to a day.

1.9 The free day and Apple DeviceCheck

Each trip gets one free park day. To stop the same iPhone from starting a new trip every day for free days, we use Apple's DeviceCheck:

• Apple keeps two yes or no values for each iPhone, for QueueWatch only. We use one to mean "this iPhone has had a free day", and Apple records the month it was set.
• When a free day starts, the iPhone app gets a one-time token from Apple and sends it to us. We ask Apple about that iPhone, and set the value if this is its free day.
• We don't keep the token. We can't tell which iPhone it was, or who owns it. The values survive deleting and reinstalling the app, and we treat them as expired after a year.
• For that trip, we record which install ids answered, and whether each was "fresh" or "used".

1.10 Technical information and logs

• Your IP address. Every connection carries one. Our server holds it in memory to limit how fast one network can make requests, so nobody can flood a trip's phones, and to note which trip codes a network has already opened. Our server doesn't write it to disk, and forgets it when it restarts.
• Our host's request logs. Our host, Railway, logs each request to our server and keeps those logs for [LOG DAYS] days. A request log may contain:
  • the time;
  • your IP address;
  • the address requested, which includes your trip code and may include a phone id or app install id;
  • your browser's or app's name and version (its user agent);
  • how the request went, such as its status, size and timing.

  Railway's documents say it may hold logs for longer than the period it shows us. We use these logs only to run the service and fix problems.

• Our server's own log lines. Our server writes short lines about how the service is running, and Railway keeps them with the request logs for the same time. A line may contain a trip code, a phone id, the start of an app install id, or Apple's transaction number for a test purchase. For example, a line is written when a free day is used or a push fails. They never contain alert text, push tokens, IP addresses or your location.
• No cookies, no analytics, no advertising, no crash-reporting tools, and no third-party code in the app.

1.11 Kept on your phone

Some things stay in your phone's own storage. We receive only what is described above.

In the web app, and in the web page inside the iPhone app:

• the trip you are on, and your phone id for each trip;
• your pause, the last ride board (for when you are offline), and display choices;
• the app install id;
• whether you have seen the intro, the "Switch parks when I arrive" setting, the last park found, and a pending trip invite;
• a list of trips your phone still needs to leave, if it was offline when you left.

The web app's service worker also keeps the app's files, and a small note of this phone's trip, phone id and pause. It uses them to show alerts correctly while the app is closed.

The iPhone app also keeps, in storage it shares with its notification and Lock Screen parts (an App Group):

• the current trip, phone id, the trip's billing id and the pause;
• up to 20 recent trips with their billing ids, so a pass can follow you;
• the Live Activity tokens it has open.

There are no cookies. Deleting the app, or clearing the site's data in your browser, deletes all of this.

1.12 What we don't collect

Your name, email address, phone number, contacts, photos, precise location, advertising identifier, health data, or anything you type besides the trip code.

2. How we use it

Only to run QueueWatch:

• sending alerts;
• showing your trip;
• keeping alerts to the rides and phones you chose;
• preventing abuse;
• checking and honoring passes;
• fixing problems.

We use our own archive of ride closures, which holds no personal data, to estimate when rides will be back.

We don't sell your data. We don't share it for advertising. We don't track you across other apps or websites. We don't build a profile of you.

3. Who else handles it

ThemeParks.wiki (ride data), NOAA's Aviation Weather Center and the Iowa Environmental Mesonet (weather) receive nothing about you. We ask them about parks and airports, never about people.

Each of these companies handles data under its own privacy terms. We share only what each needs for the job above.

We give information to the police or a court only when the law requires it. If QueueWatch is ever sold, this policy goes with it.

4. How long we keep it

5. Your choices

• Pause alerts for the whole trip, or just your phone, in the app.
• Turn off alerts for your phone: More, then Alerts on this phone, then Turn off for this phone. Its push token is deleted at once.
• Leave a trip: More, then Leave this trip. Your phone's push token is deleted at once.
• Delete a trip for everyone: More, then About QueueWatch, then Delete this trip. Its settings, phones, alerts and log are deleted at once, and from the backup.
• Turn off location or notifications in your phone's Settings at any time. QueueWatch still works: you pick the park yourself, and see ride status in the app.
• Delete the app to delete what is on your phone.
• Ask us to see or delete your data. Email [SUPPORT EMAIL] with your trip code. We don't know who you are, so the trip code is the only way we can find your data.

  We delete everything except what we must keep to honor or check a purchase: the bare purchase numbers in section 1.8, and a running pass you may want to restore. We can't delete what Apple holds. For that, contact Apple.

You don't need to give a reason, and we won't treat you differently.

6. Children

QueueWatch is for families planning park days. It isn't aimed at children. A parent may add a child's phone to the family trip. We don't knowingly collect personal information from children under 13 beyond the phone id and push token that make alerts work. Nothing about a child's name, age or location is collected. If you think we hold something about your child that you want deleted, email us with the trip code and we will delete it.

7. Security

• Every connection to QueueWatch uses HTTPS.
• Alerts to the web app are encrypted end to end (RFC 8291). Alerts to the iPhone app travel encrypted to Apple, and Apple delivers them (section 3).
• Data is stored on our host's server, which only we can reach.
• Trip codes are random, and guessing them is rate-limited.

No system is perfect. If a breach ever affects your data, we will say so in the app and on our website.

8. Your rights where you live

Depending on your state, you may have the right to know, access, correct or delete your data, and to opt out of its sale. We don't sell it. Email [SUPPORT EMAIL] to use any of these rights. QueueWatch is offered in the United States only.

9. Changes

When this policy changes, we will update the date at the top. For anything important, we will tell you in the app before it takes effect.

10. Contact

[LEGAL NAME]
[ADDRESS]
[SUPPORT EMAIL]