Security
How OutageDeck handles your account, keys, and data
Reading a product page tells you what a tool does. It rarely tells you what it stores, what it can reach, or what happens when you stop using it. This page answers those questions directly, in the same plain vocabulary the rest of the site uses.
What is stored
An account is an email address. There is no password, no profile, no company record, and no billing detail held here: payments run through Paddle as merchant of record, and card data never reaches OutageDeck. Alongside the address, an account holds the alert rules you create, the delivery destinations you configure, any custom provider feeds you add, and API keys.
Checking a provider needs no account at all. The directory, the incident archive, the multi vendor board, the badges, the feeds, and the read only API and MCP tools all work signed out, and nothing about that path is tied to a person.
Sign-in holds no reusable secret
Signing in is either a single use email link or GitHub or Google. Because there is no password, there is no password to leak. The email link is stored only as a SHA-256 hash, expires, and cannot be replayed once used: the row is consumed on the first click, so a copy of the link taken later is worthless.
The same reasoning governs the MCP authorization flow, which uses OAuth 2.1 with PKCE and stores its codes as hashes rather than in the clear.
API keys, and what a key can actually do
A key is shown once, at creation, and stored only as a SHA-256 hash. Nobody can read your key back to you afterwards, including us, which is why the recovery path is to create a new one and delete the old. Keys are created and deleted by you from the account page, and deletion takes effect immediately.
The permission model is deliberately small. A key raises your rate limits and unlocks the account tools: adding, updating, or removing your own custom provider feeds, and creating alert rules. A key cannot read another account, cannot change billing, cannot alter the shared provider catalog, and cannot send mail to an address that has not confirmed it. Every read only tool works with no key at all, so an agent that only checks status never needs a credential in the first place.
An alert can only reach someone who agreed to it
Paid plans can send alerts to a team alias, an on-call address, or a client. Paying for a plan is not what unlocks that. The plan decides whether an account may askan address to confirm; only that recipient's own click decides whether mail may be sent to it. A payment is not the recipient's consent, so it is not treated as one.
Withdrawing consent is never gated. Every alert carries a one click removal link and a standard unsubscribe header, and the recipient does not need an OutageDeck account to use either. Consent is re-checked on every dispatch rather than cached, so a removal, a revocation, or a lapsed plan stops delivery on the next run.
Credentials for your own feeds
If you point OutageDeck at an authenticated status feed of your own, that credential is encrypted with AES-256-GCM before it is stored and is write only: it can be replaced, it can be deleted, and it is never returned by any page, API response, or tool result.
Because a custom feed URL is supplied by a user, fetching it is treated as hostile input. Outbound requests resolve DNS first and pin the connection to the resolved address, which blocks the redirect and rebinding tricks used to reach private networks, and the check fails closed rather than guessing when resolution is unclear.
How long things are kept
Raw status snapshots are pruned past a 30 day window. What survives is the daily uptime rollup and the incident record, which is the part that has to stay linkable: an incident cited in a postmortem should not disappear because the vendor took its banner down.
Account data lives as long as the account. Ask from the address on the account and it is deleted, along with its alert rules, destinations, custom feeds, and keys.
Reporting a vulnerability
Send it to hello@outagedeck.com with enough detail to reproduce it. You will get a human reply. Please do not run denial of service tests or automated scanners against production, and please do not access an account that is not yours: report the path instead and it will be checked.
OutageDeck is a small independent project, so there is no bounty programme and no service level promise on triage. Reports are read and answered by the person who wrote the code.
What is not claimed
There is no SOC 2 report, no ISO 27001 certificate, and no HIPAA or PCI attestation. Saying so plainly is more useful than implying otherwise: if your procurement process requires one of those, OutageDeck does not clear that bar today, and you should know it before a trial rather than after.
What is on offer instead is a small surface and a public explanation of it. The reasoning behind the data itself is on the methodology page, and OutageDeck publishes its own status in the same vocabulary it uses for every vendor it tracks.