Privacy

What Silent Outage holds, why it holds it, how long it keeps it, and how to make it stop. The list below is generated from the same inventory that builds your data export and your account deletion, so it cannot describe a product different from the one running.

What we hold

Who you are, as far as we know

One address, so we can let you in and tell you when something breaks.

the account itself: name, tier and billing customer reference
the people in this account: the address each signs in with, their role, and which escalation rung they are paged on
invitations to join this account: the address, the role offered, and what became of it
the membership record: who invited, joined, changed role or was removed, and when
login sessions: when they started, when they expire, whether revoked
outstanding and spent login links: when issued, when used
which steps of setting the account up were reached, and when each one was

What you asked us to watch

The checks themselves. Without these there is nothing to monitor.

projects: name, business timezone and detected stack
checks: type, schedule configuration and current state
the project’s public status page: its address, its title and whether it is switched on
the words you posted yourself on the project’s status page: manual incident updates and page-level notices

What your systems told us

The heartbeats, runs and probe readings a check is made of — including whatever your job printed, up to a size limit, because that is what tells you why it failed.

received heartbeats: arrival time, outcome, duration, captured body, and whether the request came from your own job or from a test button on one of our screens
learned seasonal profiles, derived from the account’s own series
the daily summary of a check’s pings — how many arrived, how many failed and the p50/p95 duration. This is what survives the raw pings on every plan past 30 days
per-location uptime probe readings: which location, what verdict, which signal failed, the status and the latency — never anything the endpoint returned
canary measurements: latency, refusal, output length, score and token counts
the monthly canary spend ledger: the cap, what was spent against it, and when it paused
the monthly canary execution allowance: how many canary runs the account has made this UTC month, against the number its plan includes
the dependency-down detector’s consecutive-breach counter for one dependency check: how many provider samples in a row read impaired, since when, and which sample was counted last
the model-version watch’s consecutive-breach counter for one canary: how many evaluations in a row read a changed version, since when, and which run was counted last
the drift and rubric-score detectors’ consecutive-breach counters for one canary, one row per detector: how many runs in a row read outside the learned band, since when, and which run was counted last

What your payments did, in outline

Amounts, counts, currency and timing, so we can learn what a normal hour looks like for you and notice when it stops. Never who paid, and never how.

payment events, reduced at the door to five fields: amount, currency, type, occurrence time and the payment processor’s own event id
the daily summary of the project’s payment events: how many of each type and currency, and their total — the summary that outlives the individual events
the margin signal’s consecutive-breach counter for one revenue check: how many completed intervals in a row read a cost-per-successful-charge above its learned band, since when, and which interval was counted last. No cost, no token count and no model name is kept
the Stripe polling fallback’s consecutive-breach counters: how many bad polls in a row, since when, and which incident each verdict has already been paged about
that a Stripe webhook endpoint was issued, and for which project

What you pay us, in outline

Which plan you are on, whether it is paid up, and the payment provider’s own references for it. The card, the billing address and the name on it are collected and held by the payment provider — we never receive them, and we store no invoice of our own.

the subscription to Silent Outage itself: which plan, its state, the payment provider’s references, and the dates it changed

What we concluded, and who we told

Incidents, the evidence behind a verdict, and the record of each alert we tried to send.

incidents: when they opened and closed, attribution and dollar-loss range
the advisory triage summary for an incident: the one line a small language model was asked to write from the alert’s own evidence, or the reason there is none
why the attribution verdict came out as it did: one row per provider considered, with the provider’s own published headline and link
the incident timeline: that a signal arrived, when, and whether it counted
queued and sent alerts: channel, state, dedup key and timings
delivery receipts: that we attempted, when, and what happened

Where alerts go

The addresses and endpoints you confirmed. Encrypted at rest, and never shown back.

configured alert channels: kind and whether the destination is confirmed

Keys you connected

That a credential exists, of what kind, and when it changed. The value itself is encrypted under a key held outside the database.

API keys issued for the public REST API: their name, scopes and whether revoked
that a third-party credential is stored, of what kind, and when it was rotated
whether a stored third-party credential has been checked, when, and what the provider answered

The short version

Signing up asks for an email address. We do not ask for a name, a phone number or a password, and there is no password anywhere in this product to store.

That is what we ask for. It is not all we hold. Monitoring means holding your checks, the heartbeats your systems send us, whatever your jobs printed, and the shape of your payment volume. All of it is listed above, and all of it is yours: you can download every row of it, and you can delete it.

Personal data, specifically

Two things in the list identify a person or a machine, and both are stated here rather than left for you to find.

the account email — the identity the magic link is sent to — held for as long as the account exists, and removed when you delete it.
the address an invitation to join an account was sent to — held while the account exists, and removed when it is deleted — the link itself stops working after a week.
the address of whoever made a change to who has access to an account — held while the account exists, and removed when it is deleted.
the address a change of access was about — who was invited, joined, or left — held while the account exists, and removed when it is deleted.
the address a heartbeat was delivered from — the customer’s own sending host, read from the platform’s forwarded client-IP header where the edge sits behind a known proxy; retained because it is operational evidence that a ping token leaked, and used for nothing else — deleted on your plan’s heartbeat retention window, and by erasure.

What is never stored

Each of these is a property of the code rather than a promise about our intentions, and each has a test that fails if it stops being true.

Card numbers, cardholder names and anything else that identifies one of your customers. A payment event is reduced to amount, currency, type, time and event id at the door, and there is no column a fuller payload could be written into.
Your customers themselves. The payment key we accept cannot read them, and we check that before we accept it.
Passwords. There is no password column anywhere, hashed or otherwise.
A record of the device or network you signed in from. A login is not fingerprinted — no address and no browser string is attached to a session.
The contents of an alert we sent. A delivery receipt records that we tried, when, and what happened — never the message, the subject or the recipient.
What an endpoint of yours returned. An uptime check records the status, the timing and whether a keyword was present; the response body itself is never carried out of the process that read it.
What a language model wrote for you. A quality canary records lengths, timings and a score, and the completion is scored where it is held and then dropped.
Names, phone numbers, job titles, company details or anything else about you as a person. We never ask, so there is nowhere for it to go.

How long it is kept

Raw heartbeats and the bodies they carry are kept for 30 days on a paid plan and 7 on the free one, then deleted. Daily summaries — how many arrived, how many failed, how long they took — are kept longer, because a chart of last quarter does not need last quarter’s individual heartbeats.

Incidents and the alerts about them are kept for as long as your plan says. Moving to a smaller plan does not delete anything immediately: there is a grace period first, so a change of mind is reversible. Moving to a larger one does not bring anything back — deletion is deletion.

Who else touches it

These are the companies that host or handle any of it. A vendor is listed before it starts, not after.

Hetzner Online GmbH — Hosts every part of Silent Outage that runs — the ping and webhook ingestion edge, the evaluator worker, the notification dispatcher and the dashboard — and the Postgres instance behind them, so every table in the schema is at rest here. Receives: account email, ping source IP.
Amazon Web Services EMEA SARL — Runs our own uptime probes from us-east-1 and ap-southeast-1, so that an endpoint is only called down when more than one network agrees it is. Each request carries what the customer configured — the URL the check watches, the HTTP method to use, the status code the check calls healthy, the word to look for in the response (where the check sets one) and the response time above which the check counts as slow (where the check sets one) — together with the limits we compute: how long to wait before giving up and how much of the response may be read looking for that word. Nothing about the response comes back except the status code, the response time and whether that word was present: the response body is read where it arrives and never leaves AWS. The same vantage points also read the public status endpoints of the monitored providers, which is our own list rather than anybody’s data. Receives: no personal data.
Fly.io (Hyper60, Inc.) — Would host the ping and webhook ingestion edge. Receives: ping source IP. — listed in advance; not in use yet
Vercel Inc. — Would host the dashboard and the API routes, including the export and erasure endpoints. Receives: account email. — listed in advance; not in use yet
Cloudflare, Inc. — Would host the customer-facing status pages, which run on separate infrastructure from the app so that a page stays up when the app does not. Receives: no personal data. — listed in advance; not in use yet
Stripe, Inc. — The monitored payment processor. Data flows one way, from Stripe to Silent Outage, never the other way: a read-only restricted key and a webhook endpoint. Events are reduced to amount, currency, type, timestamp and event id at the door, so no cardholder data and no information about a payer is ever received. Receives: no personal data.
Brevo SAS — Sends magic-link login emails and alert emails. Receives: account email, alert destination email.
Slack Technologies, LLC — Delivers alerts to a workspace channel, where the customer has installed the app. Receives: no personal data.
Discord Inc. — Delivers alerts to a server channel, via a webhook the customer created. Receives: no personal data. — listed in advance; not in use yet
Twilio Inc. — SMS and voice escalation on the paid plans. Receives: alert destination phone number. — listed in advance; not in use yet

What is yours to do

Download everything we hold about your account, or delete the account and its data, from /account/data. Neither opens a request with us — both happen when you press the button.

access and portability (Art. 15 / 20)
erasure (Art. 17)

What deleting your account does not remove

Deletion removes every category listed above: your account, your checks, your heartbeats and their bodies, your payment figures, your incidents, your alert receipts, your destinations and your stored credentials. It is verified afterwards and it is not reversible.

These survive, and none of them is about you:

our own alerts about this service — a status feed that stopped parsing, a sweep that fell behind, a disk filling up — they are about us and have no field that could name an account, a project, a check or a destination, so there is nothing in one to delete and nothing to link back to anybody.
readings of a third-party provider’s public status page and our own probe of it — one reading per provider is shared by every customer watching it — that is what keeps us inside the provider’s rate limit — so it is not anybody’s personal data and deleting it would delete other customers’ monitoring.
the per-location detail behind those provider readings — the same shared series, split by where we measured it from.
a provider’s own published incident headline and link, captured when we read it — it is the provider’s public announcement, kept because a status page has moved on by the time anybody reads an alert about it.
how well our own readers are coping with each provider’s feed format — a measurement of our software, with no account attached.
ordinary web-server request logs on the machine that served these pages — they are the normal record of a web server running — no request body, no monitoring data and nothing joined to an account — and they age out on the host’s own schedule.
the email provider’s record of messages we asked it to send — it is their log rather than ours, kept under their retention policy; the subprocessor list names them.
encrypted database backups taken before the deletion — a backup is what makes an outage survivable, and rewriting history inside one is not something anybody can do reliably — they expire on their own rotation and are never read back except to restore the whole database.

Asking us something

Write to support@silentoutage.com, or read /support first. A data-subject request does not need a special channel — the two that matter are buttons on your own account screen.