Privacy policy
This describes what IncidentFlare does with personal data. It is written to be read rather than to be defensible, and it describes the software as it actually behaves.
For data about your own account we are the controller. For the data you put into your workspace about other people — the addresses of the people you page, and the subscribers to your status page — we are a processor acting for you, and the data processing terms govern that.
We do not publish a postal address. If you need our identity for a data protection request or to complain to an authority, ask at privacy@incidentflare.com and we will provide it.
The short version
- We do not sell personal data, and we do not serve advertising.
- We do not use anything you put into your workspace to train machine learning models, and we do not let our providers use it for that either.
- Signing in sets one cookie, the kind the law calls strictly necessary. Beyond that we measure how the site is used, which starts when you arrive and sets cookies of its own. A notice says so on your first visit, and one click there — or the Cookies link in the footer at any time — turns it off and keeps it off. Turning it off changes nothing about how the product works.
- Everything you put in comes back out in a portable format, on any plan — ask us and we will send it.
- Deleting your account deletes it, immediately, without asking anyone.
What we hold, and why
| Data | Why we have it | Legal basis |
|---|---|---|
| Your name, email address and a hash of your password | To have an account at all, and to reach you about the service | Performance of the contract |
| If you sign in with Google or GitHub: the account id they give us, the email address and name on that account, and the fact the two are linked. We do not receive a password, and we ask for nothing beyond your profile and email. | To let you sign in without another password | Performance of the contract |
| If you turn on two-factor: your authenticator secret, encrypted, and hashes of the ten backup codes | To check the second factor when you sign in | Legitimate interest in keeping your account yours |
| If you enable notifications on a device: the push subscription that browser gives us, which is an address at your browser vendor's push service plus the keys used to encrypt for it | To send an alert to that device | Performance of the contract |
| Session tokens and API tokens | To keep you signed in and to let your scripts write to your workspace | Performance of the contract |
| Your workspace: status pages, components, incidents, maintenance, monitors and their check results, alert channels, escalation policies, rotations | It is the product | Performance of the contract |
| Contact points you enter for the people you page — email addresses, Telegram chat ids, Slack webhook URLs | To deliver the alert to them | Processed on your instructions; see the data processing terms |
| Email addresses of people who subscribe to your status page | To send the updates they asked for | Their consent, given by confirming a link we email them |
| Counts of three product events — an account was created, a paid plan was clicked, the upgrade screen was opened | To know whether anyone wants the paid product. These are counts with a label, stored by us, never derived from an IP address and never linked to a profile | Legitimate interest in running a viable service |
| Upgrade requests: what you asked for, how urgent, your note | To reply to you and to decide what to build | Steps taken at your request before a contract |
| Server logs on the host, which include IP addresses and the URLs requested, and short-lived in-memory rate-limit counters keyed by IP | To keep the service up and to stop abuse | Legitimate interest in security |
Cookies, analytics and what we will not do
We do not sell personal data, we do not serve advertising, we do not record your screen or your keystrokes, and we do not buy data about you from anyone.
Your session cookie is set when you sign in and needs no permission, because without it you cannot stay signed in.
Measurement is different, and we would rather be plain about it than hide it in a definition: it begins when the page loads, before you have told us anything. We do that because knowing whether anyone is reading these pages is what tells us which of them to keep writing. The trade is that the choice is offered after the fact rather than before — a notice on your first visit, and the Cookies link in the footer after that. Turning it off stops it there and then, is remembered, and costs you nothing: no feature here depends on being measured.
European law asks for that agreement before the first such cookie rather than after. We are telling you where we stand instead of describing it as something else.
Typefaces are downloaded when the site is built, not from a font service while you read, so your browser does not talk to anyone but us.
When we check an email address
On signup and on subscribing, we check that the address is syntactically valid, is not a known disposable-mailbox domain, and that its domain has a mail server. The last check is a DNS lookup for the domain, which reaches the DNS resolver our server uses. The address itself is not sent anywhere.
Who else touches the data
We use service providers to run the product, and only for that. They act on our instructions, under a contract that binds them to at least what this policy promises, and they may not use your data for their own purposes. The categories are: hosting and databases; email, SMS and voice delivery; payment processing; error tracking and operational monitoring; product measurement and analytics; A/B testing; identity and sign-in providers; customer support; and machine learning services used for the features described below.
Which of those we name depends on whose data it is, because the two are not the same obligation.
- The data you put in about other people — the addresses of the people you page, your subscribers — is data we handle for you. Every provider that can touch it is named, with what it does and where it sits, on the sub-processors page, and we give 30 days notice before adding one.
- Data about you and about visitors to this site — your account, which pages were opened, what broke in your browser — is data we decide about ourselves. For that the categories above are the disclosure, and we may change which provider fills one without rewriting this page. Anything that needs a cookie asks you first, and says at that moment what it is.
Alerts you send to Slack, Telegram or your own webhook go where you told them to go. Those are your integrations, not ours, and what happens at the other end is governed by whatever you agreed with them.
If you turn on notifications for a device, your browser vendor's push service — Google for Chrome, Mozilla for Firefox, Apple for Safari — carries the message to it. The contents are encrypted for that device before they leave us, so the push service can see that a message was sent and roughly how big it was, but not what it says.
We will also disclose data if the law requires it, and we will tell you unless we are forbidden to.
Machine learning and automated processing
Some features work better with a model behind them — summarising a long incident, drafting an update for your status page, grouping alerts that look like the same failure, spotting a monitor that is flapping. Where a feature does that, we may send the data that feature needs to a machine learning provider acting as our processor, under a contract that forbids them from keeping it beyond the request or using it to train on.
Three limits hold regardless of which provider we use. We do not use your workspace data to train models, our own or anyone else's. We do not feed your data to a model except to produce something you asked for. And no automated decision is made about you that has a legal or similarly significant effect — models draft and suggest, people and your own rules decide.
Where it lives
Data is stored in the European Union. Where a provider is outside it, the transfer relies on the European Commission's standard contractual clauses or an adequacy decision, and the current position is on the sub-processors page.
How long we keep it
- Account and workspace data: while the account exists. Delete the account and it goes immediately, along with the workspace, its incidents and its subscriber list.
- Monitor check results and uptime history: while the account exists. They are the record behind your public uptime chart, so we do not thin them out behind your back.
- Subscribers: until they unsubscribe, or until you delete them or the page.
- Upgrade requests: deleted with the account they belong to.
- The three event counts: the count survives an account deletion, with the link to the account removed, so what remains is a number and a date.
- Server logs: rotated on the host, kept no longer than 30 days.
Your rights
Under the GDPR you can ask for a copy of your data, correct it, have it deleted, restrict or object to what we do with it, and take it elsewhere. Two of those need no request at all:
- Deletion needs no request: Settings → Delete my account. It happens straight away, and takes the whole workspace with it.
- A copy, in a portable format: email us and we will send you a machine-readable export of your workspace. We do not charge for it and we do not ask why.
For those and for anything else, email privacy@incidentflare.com. We answer within 30 days, normally much sooner, and we do not charge for it. If you are unhappy with the answer you can complain to the data protection authority where you live.
Security
Passwords are stored hashed, never in the clear. Traffic runs over HTTPS. Session and API tokens are stored as hashes, so a copy of the database does not hand over live credentials. Two-factor secrets are encrypted with a key kept outside the database, and backup codes are stored as hashes, so the same copy does not let anyone past the second factor either. Monitors and webhooks are blocked from reaching private network addresses, which stops the service being used to probe internals. Access to the production database is limited to the people who operate the service.
If personal data is ever exposed, we will tell affected customers without undue delay and within 48 hours of becoming aware, with what we know and what we are doing, even when the breach is small enough not to require it. That is deliberately tighter than the 72 hours the law allows, because you may have your own 72-hour clock to meet.
Children
The service is for people running software in production. It is not for under-16s.
Changes
When this policy changes materially we email account holders before it takes effect. The date at the bottom of the page is the version you are reading.
Contact
privacy@incidentflare.com for anything about data, or hello@incidentflare.com for everything else. A person reads it.