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 apps for iOS and Android. Where this policy talks about “the service”, it means all of them together — they are one application behind one address, and the apps hold 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, Sign in with Google or an emailed sign-in 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.
• Sign in with Google. Google gives us a subject identifier for you, your email address, whether Google has verified that address, and your name. We never receive your Google password, and we ask for nothing beyond your basic profile — no access to your mail, contacts or files.
• 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.
• Phone number. Optional, and only if you add one. It is the number an escalation policy’s call step dials to reach you, and the owner and admins of each team you belong to can see it — see section 5.
• Alert preferences. Your time zone, whether you have turned on quiet hours, and when Do not disturb ends if you have turned it on. These decide when alerts and recovery messages reach you.
• Last active. When you last used the dashboard, recorded at most once every five minutes. It is shown to the owner and admins of your teams, so they can tell an account that is in use from one that is not.
• Team name, color and time zone. Everything you own hangs off a team, which is created for you at sign-up, along with the defaults new monitors on it start from. 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, member or viewer), 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. If you name people while creating a team that does not yet have room for them, we hold their addresses and send the invitations once the plan has the seats; until then nothing is sent.
• Android beta sign-ups. If you leave your email address for the Android beta on the home page, we keep it to send you that one message, and for nothing else.

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: which people each step reaches, any phone number typed directly into a call step, the destination URL for a webhook step, and any rules about when a policy applies.
• 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 which person acknowledged it and when.
• Incident notes — anything you or a teammate writes against an incident, with who wrote it and when. Everyone who can see the incident can read them, so write them as you would a message to the team.
• 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 a phone we store its push token — Apple’s on iOS, plus a Live Activity token; Google’s Firebase Cloud Messaging token on Android — along with the device name you have given it (“Tim’s iPhone”), the app version, the OS version, the platform and when it last checked in. An Apple Watch paired to an iPhone is reached through it and is not registered separately.
• Browser notifications. If you turn them on, we store the subscription your browser gives us: an address at your browser maker’s push service and the keys used to encrypt messages to it, plus a label and when we last pushed to it.
• What stays on your device. The apps keep a local copy of your monitors and recent incidents in their own storage so they can open without waiting for the network, and your sign-in token in the device’s secure storage (the iOS Keychain, or Android’s equivalent). On iOS 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, canceling, 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. Neither app contains an 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 — skipping you while you are in Do not disturb, skipping everyone while your team has paused alerts, and holding recovery messages until morning during your quiet hours.
• 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 who on it can be reached, 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, how quickly on average, the notes they wrote, and the delivery record of alerts sent to them — and the things that decide whether an outage can reach them: the phone number on their account, the names and last check-in of the phones they have signed in on, how many browsers they have turned notifications on in, whether they are in Do not disturb, and when they last used the dashboard. If you run a team, that visibility is yours to explain to the people on it.

The rest of their account — their password and sign-in methods, their other teams and what they hold there — 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 apps pass 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 the You section of Settings, which deletes the file.

What is in an alert

An alert has to pass through somebody else’s infrastructure to reach you. A push to an iPhone goes through Apple’s push service; a push to an Android phone goes through Google’s Firebase Cloud Messaging; a browser notification goes through the push service run by your browser’s maker — Google for Chrome, Mozilla for Firefox, Apple for Safari; an email alert goes through our email provider and then your own mail server. In every case the monitor’s name, its state and the cause of the incident are part of the message. Browser notifications are encrypted so the push service cannot read them; the others are not. If a monitor name would be sensitive on a lock screen in a meeting, or in an inbox, name it accordingly.

We do not sell personal information, and we do not share it for cross-context behavioral 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 → Delete account 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 and profile photo under You in Settings, and your password under Sign-in & security.
• Change or remove your phone number, time zone and quiet hours, and revoke a phone, under How we reach you in Settings. Revoke an API token under API.
• Delete a monitor, and everything recorded against it, from the monitor’s own page.
• Delete your entire account and team from Settings → Delete account, on the website or 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 honor browser opt-out signals such as Global Privacy Control by default, because the behavior 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.