Privacy policy

This policy covers Last Seen Up (“we”, “us”) as the operator of the hosted service at lastseenup.com and the publisher of the Last Seen Up app for iOS. Where this policy talks about “the service”, it means both together — they are one application behind one address, and the app holds no account data the hosted service does not.

Cookies are dealt with separately, in the cookie policy, which names every cookie the site sets. Your rights and obligations as a customer are in the terms of service.

2.1 Your account

• Email address and name. Required — the email address is how you sign in and where alerts and sign-in codes go.
• Password. Stored only as a bcrypt hash. If you signed up with Sign in with Apple or a magic link, a random 64-character password is generated and hashed so that no password login can ever match your account; it is never shown to anyone, including you.
• Sign in with Apple. Apple gives us a subject identifier for you and an email address, which may be one of Apple’s private relay addresses if you chose to hide yours. We never receive your Apple ID password.
• Two-factor and passkeys. If you turn on two-factor authentication we store the shared TOTP secret and your hashed recovery codes. Registering a passkey stores its credential ID and public key — never anything that could be used to impersonate you elsewhere.
• Profile photo. Optional, and only if you upload one. Read the notice in section 6 before you do.
• Team name and time zone. Everything you own hangs off a team, which is created for you at sign-up. You can also belong to other people’s teams; the name of a team you are in is shown to everyone in it, and labels any monitor shared with you.
• Team membership and roles. Which teams you belong to, your role in each (owner, admin or member), and — if you are a member with restricted access — which individual monitors you have been granted.
• Invitations. If you invite somebody, we store the email address you typed, who sent it, and when it was accepted or expired, so the invitation can be delivered and redeemed. The link itself is kept only as a hash — we cannot reconstruct it, and re-inviting the same address replaces the pending invitation rather than leaving two live links.

2.2 What you configure

This is the largest category and the one most likely to contain something sensitive, because you decide what goes in it:

• Monitor settings. The URL, hostname, port, or domain being watched; the HTTP method, request headers, request body, expected status codes and content match strings; expected DNS records; how often to check, how long to wait, and how many failures it takes to call something down.
• Credentials inside those settings. HTTP basic auth usernames and passwords, and any authentication header you add, are stored so the check can be made. See section 6.
• Escalation policies. The ladder of who gets told and when, including phone numbers for the call step and destination URLs for the webhook step.
• Heartbeat tokens. The secret in a heartbeat URL, plus whatever your job sends in the optional JSON body when it checks in — typically an exit code, a duration and a short message. We cap what we keep from that body; we do not filter it, so do not put secrets in it.
• Maintenance windows and tags. Including any reason you type against a window.

2.3 What monitoring produces

• Individual check results — timestamp, region, up or down, response time, HTTP status code, an error code, and a small metadata document that can include the redirect chain, the response content length, or a truncated error message from the failure itself. Response bodies are not stored.
• Hourly rollups — counts of checks and failures, and typical, worst-case and maximum response times per monitor per region.
• Incidents — when one opened and closed, what caused it, which regions were failing, the full timeline of state changes, and who acknowledged it.
• Heartbeat state — when each job last checked in, and whether it reported success or failure.
• Certificate and domain records — for a TLS or domain monitor, we fetch and keep what the public registries publish about the name you gave us: the certificate’s issuer and expiry, and the registrar, nameservers, status codes and expiry date from the domain’s public RDAP or WHOIS record, along with a history of what changed between checks. This comes from the registry, not from you, and it is public information — but where a registration is held in a person’s own name rather than a company’s, that record can contain their details. We keep it because a domain quietly changing hands or lapsing is the thing the monitor exists to catch.

2.4 Devices and delivery

• Device records. When you sign in on iOS we store the Apple push token and Live Activity token for that device, the device name you have given it (“Tim’s iPhone”), the app version, the OS version and the platform. An Apple Watch paired to that iPhone is reached through it and is not registered separately.
• What stays on your device. The app keeps a local copy of your monitors and recent incidents in its own storage so it can open without waiting for the network, and your sign-in token in the iOS Keychain. The widgets, the watch app and the notification extensions read that same local copy. None of it is separate data we hold — deleting the app removes all of it.
• Delivery records. For every notification: the channel, the target it went to, the provider’s identifier for it, whether it was delivered, and the error if it was not.
• API tokens. Stored hashed. Each is bound to the device it was issued to, so revoking one revokes the other.

2.5 If you subscribe

A paid plan is bought either on this website or through the App Store, and in both cases the money is handled by somebody else. We never receive, see or store your card number.

• Bought on the website. Stripe processes the payment. We send them the billing email address and the team name to create a customer record, and we keep the identifier they give us back so that a renewal two months later can be matched to the right team. Your card details are entered on Stripe’s own pages and are held by Stripe, not by us.
• Bought in the app. Apple processes the payment and tells us the result. We never learn your payment method. So that Apple’s notification can be matched to your account without Apple being told who you are, the app sends a random identifier with the purchase that means nothing outside our database.
• What we keep either way. Which plan the team is on, whether the subscription is active, cancelling, past due or expired, when the current period ends, which of the two took the payment, and that provider’s identifier for the subscription. This is what decides your limits, so it is read on nearly every page.

2.6 Collected automatically

• Server logs. Ordinary web server and application logs — IP address, user agent, the path requested, the response status and the time. Used to keep the service running and to investigate abuse.
• Session and security cookies. Listed individually in the cookie policy.

2.7 What we do not collect

There are no analytics on this site, no advertising or tracking pixels, no third-party scripts, no session recording, and no cross-site tracking of any kind. We do not build a profile of you, and there is nothing here to fingerprint you with. The iOS app contains no analytics SDK.

• Running the checks you asked for and recording what they returned.
• Deciding when a monitor has changed state, opening and closing incidents, and sending the resulting alerts down your escalation policy.
• Signing you in, keeping you signed in, and enforcing two-factor authentication where you have turned it on.
• Showing you your own history — charts, uptime figures, incident timelines and delivery records.
• Answering your support requests, and telling you about changes to the service that affect you.
• Taking payment if you subscribe, working out what your plan entitles you to, and keeping the accounting and tax records that go with it.
• Letting the people on a team see the team’s monitors, and delivering invitations to the addresses their colleagues supply.
• Keeping the service secure and available: rate limiting, abuse investigation, debugging, and capacity planning.
• Meeting legal obligations, and enforcing our terms.

We do not use your data to train machine learning models, we do not sell it, and we do not share it for anyone’s advertising.

Where the UK GDPR or EU GDPR applies, we rely on:

• Contract — everything needed to provide the monitoring you signed up for: your account, your monitors, the check results, and the alerts.
• Legitimate interests — keeping the service secure and reliable, investigating abuse, and improving it. Balanced against your interests, and narrow: there is no profiling and no marketing analytics riding on this basis.
• Legal obligation — tax, accounting and responding to lawful requests.
• Consent — where we ask for it, such as optional preference cookies. You can withdraw it at any time without losing access to anything essential.

A monitor is pointed at a system that is usually somebody else’s responsibility, and the data it produces is about that system rather than about a person. Even so, some of what you put into Last Seen Up may be personal data belonging to third parties — a colleague’s phone number in an escalation policy is the clearest example.

For that data you are the controller and we are your processor: we act on your instructions, and we do not use it for anything but delivering the service. You are responsible for having a lawful basis to give it to us, and for telling the people concerned. If you need a written data processing agreement, email [email protected].

Inviting somebody to a team

Sending an invitation means giving us an email address that belongs to somebody else, and it is the most common way this happens. You confirm you are entitled to do that. We use the address to deliver the invitation and for nothing else — no marketing, and no account is created until the person accepts.

Once they accept, the team owner and its admins can see what that person does on the team’s monitors: which incidents they acknowledged, and the delivery record of alerts sent to them. If you run a team, that visibility is yours to explain to the people on it. Their own account — their name, their address, their other teams — is theirs, not the team’s, and removing somebody from a team ends their access to your monitors without touching anything else about them.

Heartbeat tokens

A heartbeat URL is a bearer credential: anyone who has it can tell us your job ran. It grants nothing else — no read access, no account access — but treat it as a secret and keep it out of public repositories and shared CI logs.

Profile photos are publicly readable

If you upload a profile photo it is stored on a public disk and served from an unauthenticated URL. The filename is random and effectively unguessable, but anyone you give the link to can open it, and so can anyone who obtains it. This is deliberate: the iOS app passes the URL to an image loader that knows nothing about bearer tokens. Do not upload anything you would mind being seen. You can remove it at any time from Settings → Profile, which deletes the file.

What is in a push notification

Alerts are delivered through Apple’s push service, which means the monitor’s name, its state and the cause of the incident pass through Apple’s infrastructure in order to reach your lock screen. If a monitor name would be sensitive on a lock screen in a meeting, name it accordingly.

We do not sell personal information, and we do not share it for cross-context behavioural advertising as the California Consumer Privacy Act defines those terms. We disclose data to the following service providers, only to the extent each one needs it to do its job:

We will also disclose data where the law requires it, to establish or defend legal claims, or to prevent imminent harm — and, if the business is ever sold or merged, to the acquirer, who takes it subject to this policy. Where we can lawfully tell you about a legal demand for your data first, we will.

Our email and hosting providers are named on request at [email protected].

Deleting your account from Settings → Profile removes your account, your team, and everything belonging to it. Backups are the exception: a deleted record can survive in an encrypted backup for up to 30 days before it ages out. We do not restore deleted accounts from backups.

• All traffic to the service and the API is over HTTPS.
• Passwords are bcrypt-hashed. API tokens and recovery codes are stored hashed. We cannot read any of them.
• Two-factor authentication is enforced on the API, not only on the dashboard — an account with 2FA turned on cannot be signed into from the app with a password or a magic link alone.
• A password reset revokes every other token on the account. Someone resetting is locked out or believes they were compromised, and leaving the other sessions alive would make the reset meaningless.
• Another team’s record answers 404, not 403 — you cannot confirm that something exists by asking for it.
• Sign-in codes and password-reset codes are held in separate namespaces, so a code that grants a session can never be redeemed to rewrite a password.

Who at Last Seen Up can see your data

We would rather say this plainly than let you assume something more flattering. Last Seen Up is run by a very small number of people, and operating it means being able to reach the database and the logs — there is no version of running a service where nobody can. Access is limited to the people who run it, over the operational dashboards, and it is used to keep the service working, to investigate a fault or abuse, and to answer a support request you have sent us.

Two things follow that are worth stating. Your monitor configuration is readable by those people, credentials included — which is the whole reason for the notice in section 6. And an operator who is invited onto your team joins it as an ordinary member with whatever access you gave them; nothing about running the service quietly widens what they see on your screens or changes what your team is billed.

No system is perfectly secure, and we will not claim otherwise. If we discover a breach affecting your personal data, we will notify you and the relevant regulator within the time the law requires. To report a vulnerability, email [email protected] — we will not pursue action against good-faith research that does not degrade the service or touch other people’s data.

The hosted service runs in the United States. If you are outside the US, using it means your data is transferred there and to the providers listed in section 7. Where those transfers are from the UK or the EEA, they rely on the Standard Contractual Clauses or the UK Addendum. Checks originate from whichever monitoring regions your account uses; on this installation that is a single region.

Depending on where you live, you may have the right to access your data, correct it, delete it, receive a portable copy, object to or restrict certain processing, and withdraw consent. You will never be treated differently for exercising any of them.

Things you can do yourself, right now

• Change your name, email address, password and profile photo in Settings → Profile.
• Revoke a device or an API token in Settings → Devices and Settings → API tokens.
• Delete a monitor, and everything recorded against it, from the monitor’s own page.
• Delete your entire account and team from Settings → Profile, or from Settings → Delete account in the iOS and Android apps. If you still own a team that other people are in, we refuse until you remove them or ask us to transfer ownership — deleting it would take their monitors and their access with it, and your confirmation is not their consent.
• Ask us to delete an account you can no longer sign in to at lastseenup.com/delete-account. We confirm the address is yours before anything is removed.
• Change or withdraw your cookie choice from the cookie settings link in the footer of any public page.

Everything else

Email [email protected] from the address on the account. We will verify who you are and respond within 30 days, or 45 where the California Consumer Privacy Act applies, extending only where the law permits and telling you if we do. If we refuse a request we will say why, and you can appeal by replying.

UK and EEA. You can complain to your supervisory authority — in the UK, the Information Commissioner’s Office. We would rather you came to us first, but you are not required to.

California and other US states. You have rights to know, delete, correct and port, and to opt out of sale, sharing and targeted advertising. There is nothing to opt out of: we do none of those things. We honour browser opt-out signals such as Global Privacy Control by default, because the behaviour they disable does not exist here.

The service is for professional use and is not directed at children under 16. We do not knowingly collect their data. If you believe a child has given us personal data, email [email protected] and we will delete it.

We may update this policy. The effective date at the top changes whenever we do. If a change materially affects your rights or what we do with your data, we will tell you by email or in the dashboard before it takes effect, and never make it retroactive. Continuing to use the service after that date means the updated policy applies to you.

• Privacy questions and data requests: [email protected]
• Security reports: [email protected]
• Legal notices: [email protected]
• Anything else: [email protected]

We do not publish a postal address. For legal notices or service of process, email [email protected] to arrange delivery.