Privacy Policy

Effective date: July 11, 2026  ·  Last updated: October 11, 2026

Raretell ("Raretell," "the App," or "the Service") is operated by Redoubtable LLC ("we," "us," or "our"), a Virginia limited liability company. This Privacy Policy explains what personal information we collect, how we use and share it, and the choices and rights you have.

It covers both the iOS App and our website at raretell.com. Most of this document is about the App, because that is where nearly all of the collection happens; Section 3.5 covers the website separately, and every section from 7 onward applies to both.

By using the App or the website you agree to the collection and use of information as described here. If you do not agree, do not use them.

1. The short version

Raretell is a passive safety net for people who live alone. Your phone periodically sends the server small signals that you are active (mainly step counts and a few device readings); the server holds a timer, and if those signals go silent for a long time and you don't respond to a check-in, it notifies the emergency contacts you chose. In plain terms:

• We collect the minimum to run the safety net: evidence-of-life signals (steps, battery/charging, connectivity), your device's most recent location, and the contacts and observers you add.
• We don't keep a location history. We store only your single most recent location fix and overwrite it on every check-in. We never track you in real time and never spin up GPS. It is shared with your chosen contacts during an active alert only if you chose to share it.
• We do not sell your personal information, and we do not use it for advertising. There are no ad networks or third-party analytics SDKs in the App.
• Health data (steps) read via Apple HealthKit is used only to run the safety net — never for advertising, marketing, or data mining, and never shared with third parties for those purposes.
• We share information with only the processors needed to run the Service — our cloud provider (Cloudflare), Apple's push-notification service, and Apple's in-app purchase billing — plus the emergency contacts and observers you choose, which is the whole point of the product.

The sections below are the complete and controlling detail.

2. Who this policy covers

The App has three kinds of people around a single account:

• Subjects — the monitored person who installs the App on their phone and owns the account.
• Emergency contacts — people a Subject invites to be notified if the Subject goes silent. A contact confirms by email and can opt out at any time.
• Observers — people a Subject adds by email or approves after they ask to watch, who sign in with their own email address to view a coarse "all's well / away / trying to reach them" status.

This policy applies to all three. Where a right or practice is specific to one role, we say so.

It also applies to visitors to raretell.com, who need not be any of the three — see Section 3.5.

3. Information we collect

3.1 Information you provide

• Your name (optional). The App asks for your full name, because it appears on every alert and status page so there is no doubt who an alert is about. You may skip it or give a shorter name; the App works without it.
• Backup email ("other ways to reach you"). A Subject's own email address, so an alert can also reach them if their phone is off, dead, or lost. A confirmed backup address is required to finish setting up an account. It is not one channel among several: it is the address we try before anyone else is told, and the only way back into an account on a new phone. Confirmation is a code we email you and you type into the App — an address that has been entered but not confirmed does neither of those jobs, so entering one is not enough. Afterwards the two ways to remove it differ, deliberately: in the App you can replace it with another confirmed address but not simply drop the last one, while the "stop emailing me" link in the email itself always works, unconditionally — whoever holds that inbox may no longer be you.
• Emergency contacts and observers. When you invite a contact or add an observer, we collect the email address and any name or label you enter for that person, and we record whether they have confirmed or opted out. You can also share a request link; someone who uses it gives us their own name and email address so you can approve or decline them, and nobody sees your status until you approve. Contacts are added by a double opt-in: we email them an invitation and they must accept before they receive any alert or count as coverage. A confirmed contact may also receive an essential notice that monitoring is materially changing or ending, because they must not continue to assume they will be alerted for that person.
• Purchase and sponsorship information. We record the plan, payment provider, subscription status, renewal/expiration status, and which protected person is covered. If someone sponsors coverage for another person, we record the payer-to-covered-person entitlement. We do not collect full card numbers in the App.
• Your acceptance of our Terms. When you tap "Get started" or "Restore" on the welcome screen, we record that your account accepted the Terms: which version, which button, the time on your phone, and the time we received it.
• Support communications. If you contact us, we keep what you send us (e.g. your message and email address) to respond.

3.2 Information collected automatically from your device

To run the safety net, the App sends the server a small "heartbeat". Heartbeats are kept only while Raretell is monitoring you — during a subscription, a free trial, or a complimentary plan; during the seven-day notice period after one ends; and until any alert already in progress is resolved. Outside those times nothing is watching for you, so the App stops sending them once it knows, and our server discards any it still receives — recording only when the App was last in touch. A heartbeat contains:

• Step activity — recent step counts and whether step data is available, read from Apple HealthKit and/or the device motion sensor. (See Section 5 for our HealthKit-specific commitments.)
• Device readings — battery level, whether the device is charging, the device's time zone, what woke the app (e.g. a background refresh, a step update, or a location change), and the app's version number.
• Connectivity diagnostics — network path and interface state, the cellular radio technology reported by iOS, and the previous server attempt's outcome, error code, and request-to-callback completion time. The timing can include iOS suspension; it is not clean network round-trip time. These fields contain no message content, Wi-Fi network name, browsing history, or carrier account identifier.
• Location — your device's most recent cached location (latitude, longitude, and its accuracy), when you have granted location permission. See Section 6 for exactly how location is handled and how little of it we keep.
• A push notification token — an Apple-issued identifier that lets us deliver check-in prompts and alerts to your device.

3.3 Identifiers

• Account identifier. Your account is keyed to an identifier created on your device and kept in the device keychain. We do not require your name, your phone number, or an Apple ID / login to create an account. (A confirmed backup email address is required to finish setting up — see Section 3.1.) The identifier is not your device's serial number, its advertising identifier, or anything else that identifies the hardware itself. What it is, on a new install, is Apple's identifier for vendor — a value iOS generates for our apps on your device, never shared with other developers, and regenerated by iOS once the last of our apps is deleted. Because it can therefore be the same across our own apps on one device, we describe it that way rather than calling it random: a claim you cannot check is worth less than one you can. Once created, the identifier stays in the keychain, so reinstalling the App reclaims the same account rather than leaving your contacts watching an account you no longer use.
• Registration abuse ledger. On a sign-up attempt, we store the connecting IP address and timestamp in our database to enforce rolling signup limits. The row is not attached to the account record and cannot be removed by the in-app account-deletion control. Its deletion target begins after 48 hours (the 24-hour limit window plus one day of cleanup slack). Your account's own sign-up record keeps a one-way hash of that address rather than the address itself. The hash lets us see that two sign-ups came from the same place without holding where that is, so the only raw address we keep is the ledger row above, deleted on the first daily run after it is 48 hours old.
• Device check. When the App creates an account it can ask Apple for a proof that it is a genuine, unmodified copy of our App running on real Apple hardware, which we check to tell real installs from fabricated ones. We keep the result of that check, and the key identifier Apple issues for the proof, with your account's activity record — so it is deleted with your account and otherwise ages out after 90 days (Section 8). The identifier is generated by Apple for this purpose; it is not your device's serial number, tells us nothing about your device or you, and is used for nothing but this check. Today the check only ever observes — a proof that fails, or never arrives, does not stop anyone creating an account. The separate ledger that makes each proof usable only once is described in Section 8.
• Outbound-email ledger. We record that an invitation or confirmation email was sent — an account identifier, the kind of message, and a timestamp — to enforce a rolling send cap that protects the delivery of real alerts. Rows for account-recovery emails are keyed by the email address instead, because no account identifier is available at that point. A recovery row also holds a one-way hash of the network address the request came from, so we can limit how many recovery emails one network can trigger; the hash cannot be turned back into the address. See Section 8 for how long these last and what account deletion reaches.
• Technical logs. Like any internet service, our servers and hosting provider process technical request data (including IP addresses and timestamps) to deliver and secure the Service. Cloudflare retains these operational logs for no more than 7 days on the configured service; they cannot be deleted individually before that fixed schedule.

3.4 What we do NOT collect

• We do not keep a location history or movement trail. We retain one latest fix; a newer fix overwrites it, and nothing in our live database accumulates a trail. Our provider's automatic restore points, kept for up to 30 days (Section 8), are copies of the whole database, so they can still hold an earlier fix until they expire. If your phone has been offline, the beats it saved up each carry the fix that was current when they were taken, so several older fixes can arrive at once when it reconnects — we keep only the newest and discard the rest. Those saved-up beats live on your phone, not with us, and the App discards any older than seven days the next time it runs.
• We do not collect contacts from your address book automatically — only the specific people you choose to add.
• We do not collect health data other than step activity used for liveness detection.
• We do not use advertising identifiers, ad networks, or third-party analytics/marketing SDKs.

3.5 Our website (raretell.com)

Everything above describes the App. Our website is a separate system with its own much smaller collection, and it is the only part of the Service that involves marketing:

• The waitlist is closed. Until October 2026 the site offered an optional waitlist that stored an email address, the headline variant shown, where the visitor arrived from, and whether they signed up for themselves or someone else. We closed it in October 2026 and deleted every entry. The site no longer asks for an email address.
• Two first-party cookies. sw_v records which headline variant you were shown, so it stays the same on later visits rather than changing under you. sw_src records the referral value from your first visit. Both are set by us, read by nobody else, and used for nothing but the two purposes just named. We set no third-party cookies, no advertising cookies, and no analytics cookies.
• A page-view counter. We increment a per-variant total. It is a single number per variant, not a record of your visit, and it is not linked to you.

The website serves no JavaScript, runs no advertising or analytics SDKs, and sets no tracking pixels.

4. How we use information, and our legal bases

We use the information above to:

We do not use your information for advertising, for building marketing profiles, or for any automated decision-making that produces legal or similarly significant effects about you.

5. Apple HealthKit

Washington and Nevada residents: step activity and location are also covered by our separate Consumer Health Data Privacy Policy, which describes the categories we collect, who receives them, and the rights those statutes give you.

The App reads step count data through Apple HealthKit to detect signs that you are active. We commit that:

• HealthKit data is used solely to provide the App's safety features (detecting activity and inactivity).
• We never use HealthKit data for advertising, marketing, or data-mining purposes.
• We never sell HealthKit data or share it with third parties for advertising or marketing.
• We do not store detailed health records. What reaches our server is a small derived signal — recent step counts and a flag indicating whether step data is available — not your Health app history.

You can revoke HealthKit access at any time in the iOS Settings → Privacy & Security → Health screen. If you do, the App continues to run in a reduced mode using other signals, and it will tell you it is doing so.

6. Location

Location is used to (a) help wake the app when you move, (b) provide a last-known location in an alert so your contacts know where help might be sent if you go silent, and (c) help tell "about to lose signal" apart from "something is wrong" — boarding a flight, heading somewhere remote. Today that means studying location alongside connectivity data internally to improve how the App handles coverage gaps; in future it may also let the App offer to pause monitoring before an ordinary silence looks like an emergency. Our handling is deliberately minimal:

• Latest-only, no trail. We store only your single most recent location fix and overwrite it on every heartbeat. We do not keep a history of where you have been.
• Never advertising, never profiling, never sold. We do not use your location for advertising or marketing, do not build advertising or behavioural profiles from it, do not sell or share it with data brokers, and do not use it to track you across other companies' apps or websites. These four are absolute.
• We do analyse it internally, to make the safety net work better. While we hold it, we may study location alongside connectivity data to improve the App's own features — chiefly telling "about to lose coverage" apart from "something is wrong," so we alert you less often for the wrong reason. This is our own engineering on our own service. It is not shared, not sold, and not used for any of the four purposes ruled out above.
• Cached fixes only; we never actively track you. The App reads the location iOS already has cached; it does not turn on GPS to locate you in real time.
• You control precision. If iOS "Precise Location" is on, the cached fix is as accurate as iOS has it; if you turn Precise off, fixes drop to approximately city-block/kilometer scale, and the App's dashboard tells you so.
• Alerts include last-known location only if you choose. During setup the App asks whether to share it, with "share" and "don't share" offered equally; until you say yes, alerts leave it out. If you share it, your contacts see your last-known fix labeled with its age (never presented as "current"). You can change your choice at any time in the App.
• Denying location does not break the safety net. The core inactivity detection runs on step activity, not coordinates. If location permission is never granted, we hold no location. If you turn it off later, the App stops sending new fixes, but the one we already hold stays until it is replaced or you delete your account — and an alert still includes it if you chose to share location. To stop that, turn alert location off in the App.

Where location is shown to a casual observer status page, it is not included — observer pages are reassurance-only and do not reveal your location.

7. How we share information

We share personal information only as described here. We do not sell personal information, and we do not share it for cross-context behavioral advertising.

7.1 With the people you choose

The purpose of the App is to notify people you designate. Accordingly:

• Emergency contacts you add receive alerts if you go silent, which may include your name, the nature of the alert, and — only if you chose to share it — your last-known location and its age.
• Observers you add or approve can view a coarse status ("all's well," "away," or "trying to reach them"). Observer status pages do not reveal your location, your activity timestamps, or raw sensor data.
• Viewing works both ways: when an observer checks your status, we record it and show you when and how often each observer has looked in. Observers are told this when they are invited and on the page where they check.

You control these relationships and can remove a contact or observer at any time.

7.2 With service providers (sub-processors)

We use a small number of processors that handle data on our behalf under contractual confidentiality and security obligations:

We do not use third-party advertising networks, data brokers, or third-party analytics providers.

7.3 For legal and safety reasons

We may disclose information if we believe in good faith it is necessary to comply with a law, regulation, legal process, or governmental request; to enforce our Terms; or to protect the rights, property, or safety of our users or others.

7.4 Business transfers

If we are involved in a merger, acquisition, financing, or sale of assets, personal information may be transferred as part of that transaction. We will require the recipient to honor this Privacy Policy or notify you of any material change.

8. Data retention

• Activity and event history (heartbeats, connectivity diagnostics, and alert/escalation events) has a 90-day retention target and is deleted by the next successful daily retention run after passing that age.
• Location is retained as your single most recent fix only, overwritten on every heartbeat.
• Removed contacts, observers, and watch requests. When you remove a contact or observer, or one removes themselves, the record of that relationship (including their email address) is kept for 90 days so your history of who was watching stays accurate, then deleted on the daily run. A request to watch that you approve or decline is kept for 90 days after your decision; one you have not yet answered is kept until you answer it or delete your account.
• Account data (your identifier, optional name, contacts, observers, and settings) is retained for as long as your account is active. It is deleted when you delete your account or, if the whole Service ends, beginning 90 days after monitoring ends, subject to any retention required by law. If you never start a subscription and the App has not contacted our server for 30 days, we delete the account and its data automatically, exactly as if you had used the deletion control yourself.
• Registration IP ledger rows have a deletion target beginning after 48 hours and are removed by a subsequent successful daily retention run. They are outside the account graph and are not removed by account deletion. The same applies to the device-check challenge ledger. The App can offer proof that it is a genuine, unmodified copy running on real Apple hardware; to make that proof usable only once, we first hand out a one-time random challenge. A row is written when a challenge is requested — before any proof is offered, and whether or not any proof ever follows. It holds an IP address, timestamps and the challenge's one-way hash, never the challenge itself. Because that endpoint is open, this includes requests that never lead to a registration and requests made directly by any other client, and a row is not removed if the proof that follows turns out to be invalid. Those rows carry the same 48-hour deletion target on the same daily job and are likewise outside the account graph.
• Outbound-email ledger rows record that an invitation or confirmation email was sent, so we can enforce a rolling 24-hour cap that protects the delivery of real alerts. A row holds an account identifier, the kind of message, and a timestamp — not the message, and not, in the ordinary case, any address. Their deletion target begins after 48 hours. The one exception: a row for an account-recovery email is keyed by the email address the recovery was requested for, because at that moment there is no account identifier to key it by. It also holds a one-way hash of the network address the recovery request came from, used only to cap recovery emails per network, and deleted with the row. Deleting your account removes the ledger rows for addresses your account holds as confirmed; an address that was never confirmed — a mistyped one, for instance — ages out on the 48-hour schedule instead.
• Deletion receipts. When you delete your account we record a receipt so that a phone whose confirmation was lost can still be told the deletion succeeded, rather than being left unable to tell "deleted" from "rejected." A receipt is a one-way hash and a timestamp — it contains no account identifier, no email address, and nothing that links it back to you or to the account it refers to. Its deletion target begins after one year. After that, an ancient unmatched request is treated as unproven/signed out rather than as proof the account still exists.
• Provider restore points. Our database provider automatically keeps point-in-time restore points so a database can be recovered after a failure or a mistake. They retain a copy of the database as it stood at each point for up to 30 days, after which they expire on their own. ⚠ A single record cannot be removed from them, by us or by anyone — the mechanism restores a whole database to a past moment; it does not support editing the past. So when you delete your account, the deletion is immediate in the live database and nothing can serve or read that account again, but a copy of the pre-deletion state remains inside the provider's restore window until it ages out. We do not query restore points in normal operation, and we would only use one to recover from a failure. This is the second place (with operational logs, below) where deletion is bounded by time rather than immediate, and we state it for the same reason.
• Operational logs are retained by Cloudflare for a fixed maximum of 7 days and cannot be purged individually before they age out.
• Observer and contact sign-in data. When a contact or observer signs in to check on someone, we store their email address together with a hashed session token, so the page remembers them. A sign-in session stays valid for a rolling 30 days from the last time it was used; once it lapses, the daily cleanup deletes it after one further day. The one-time sign-in link we email is stored the same way and expires within minutes; the daily cleanup deletes it about a day after it expires. This data belongs to the contact or observer, not to the person they are checking on — so it is not removed when that person deletes their account. A contact or observer who wants theirs removed can email us, and removing yourself as a contact (the link in every alert) is unaffected either way.
• Waitlist entries (Section 3.5): none are held. The waitlist closed in October 2026 and every entry was deleted; the website's daily two-year purge that covered them still runs.
• Terms acceptances (Section 3.1) are kept for as long as your account exists, so we can show which version of the Terms was agreed to and when. They are never edited after they are written, and they are deleted with your account.
• Daily service totals. Once a day we record counts across the whole Service, such as how many accounts exist, how many are subscribed, and how many alerts started or ended that day. These totals contain no account identifier, name, email address, location or health reading, and no record of any one person. We keep them for as long as the Service runs, to understand how it is used and whether it works, so they are not removed when an account is deleted. While the Service is small, a total can correspond to very few people; only the operator sees them.
• Support communications are kept as long as needed to resolve your matter and then for up to two years, unless a longer period is required by law or needed for an active legal claim.

9. Security

We design for data minimization as a security control: keeping only the latest location fix and short activity windows limits what a breach could expose. Data in transit is encrypted (HTTPS/TLS), and access to production systems is restricted. No method of transmission or storage is perfectly secure, and we cannot guarantee absolute security.

10. Your privacy rights

Depending on where you live, you may have some or all of the rights below. We honor these rights regardless of where you live to the extent practicable.

10.1 Everyone

• Access the personal information we hold about you.
• Correct inaccurate information (e.g. your display name or a contact address).
• Delete your account and account-linked personal information immediately from our live database, after which nothing can serve or read that account again. Some records are not removed by that control, and Section 8 describes every one of them in full: the registration IP ledger and the outbound-email ledger both begin aging out after 48 hours; our provider's automated restore points hold a copy of the pre-deletion database for up to 30 days, from which no single record can be removed, and then expire; provider operational logs age out within 7 days; a deletion receipt — a bare hash and timestamp holding nothing that identifies you — begins aging out after one year; and contact/observer sign-in data belongs to those people rather than to you, so your deletion does not reach it.
• Withdraw consent for health or location processing at any time (via iOS permissions and in-app settings); this does not affect processing already carried out.

10.2 California residents (CCPA/CPRA)

You have the right to know what personal information we collect and how we use and disclose it, to request deletion, to correct inaccurate information, and to limit use of sensitive personal information. We do not sell or share personal information as those terms are defined under the CCPA/CPRA. We use sensitive personal information (step data and precise geolocation) only to provide, secure, maintain the quality and safety of, and improve the Service itself. We do not use it to infer characteristics about you, and never for advertising, marketing, profiling, or sale. We will not discriminate against you for exercising your rights.

10.3 EEA, UK, and Switzerland residents (GDPR / UK GDPR)

Our legal bases are described in Section 4. In addition to the rights above, you have the right to object to or restrict certain processing, the right to data portability, and the right to lodge a complaint with your local data protection authority. Where processing is based on consent, you may withdraw it at any time. The data controller is Redoubtable LLC.

10.4 How to exercise your rights

Email privacy@raretell.com or use the account deletion control in the App. We may need to verify your request. Because accounts are pseudonymous (keyed to a device-generated identifier rather than your name or email), verification and fulfillment are generally performed from the device that holds your account. We will respond within the timeframes required by applicable law.

11. International data transfers

We are based in the United States, and our processors may store and process data in the United States and other countries. If you use the App from outside the United States, you understand your information will be transferred to and processed in the United States.

12. Children's privacy

The App is not directed to children under 13, and we do not knowingly collect personal information from children under 13. In the EEA/UK, the App is not directed to children under 16. Our Terms require account holders to be adults. If you believe a child has provided us personal information, contact us and we will delete it.

13. Changes to this policy

We may update this Privacy Policy from time to time. If we make material changes, we will update the "Last updated" date and provide notice appropriate to the change, which may include the App, push notification, your backup email, and — when the change affects whether they will be alerted — your confirmed contacts. If a new use of information requires affirmative consent, we will request it before that use; continued use alone is not consent where the law requires an opt-in.

14. Contact us