keelnest
Start free

What we collect, and why.

This policy explains what personal data Keelnest processes when you visit our site, run the free health check, or use the service, and the choices you have. It is written to be read, not skimmed past.

Effective 25 September 2026

1. Who we are

Keelnest (“we”, “us”) provides monitoring, publish verification and cost tracking for web applications. For data you give us as a customer, we are the controller. For observation data that comes from your applications and your customers, you are the controller and we process it on your instructions under these terms and the Terms of Service. Contact us at privacy@keelnest.com.

2. Data we collect from you

  • Account data. Name, email address, workspace name, the sign-in method you choose (email link, password, Google, GitHub, your company’s single sign-on or a passkey), your two-step sign-in secret and backup codes if you turn it on, profile picture if your identity provider supplies one, and your role in each workspace.
  • Billing data. Your tier, invoices and payment status. Card details are entered directly with our payment processor, Polar, and never reach our servers.
  • Configuration. The applications you add, their URLs, the providers you connect, journeys you confirm, budgets, response targets, clients and maintenance plans.
  • Provider credentials. OAuth tokens, GitHub App installations, Stripe restricted keys and provider admin keys you connect, and the client secret of an identity provider an owner connects for single sign-on. See section 6 for how they are protected.
  • Communications. Emails you send us, support requests and survey answers.

3. Data we collect by observing your applications

This is the data the product exists to collect. It is scoped to the applications you add and the providers you connect.

  • Availability and configuration. HTTP responses, response times, TLS certificate details, the domain’s renewal date and registrar from its public registry record, security headers, redirect and origin settings, and the names of environment variables compared between publishes. Values are never stored.
  • Deployments. Deployment metadata, commit identifiers, changed file paths and webhook payloads from Vercel, Netlify and GitHub, or a build fingerprint when a builder does not report publishes.
  • Dependency alerts. On Studio and above, with GitHub connected: whether Dependabot alerts are on for each repository an app is built from, how many are open by severity, and the package names and advisory titles of those with no fix yet. Nothing is changed on GitHub.
  • Journeys. Results of the browser walkthroughs you confirm, with timings, assertions and, when a run fails, one sanitized screenshot of the page it failed on. Test accounts are stored as secret references. A payment journey stops before the pay step, so nothing is charged and no test payment method is stored.
  • Key pages. After each publish, what your key public pages show in a browser: the title and search-engine tags, links, buttons and forms, which outside sites they load code from, and one sanitized screenshot. Keelnest never signs in, clicks or types on them.
  • Payments. Hourly aggregates of payment counts and totals, webhook endpoint health and event types from Stripe. We do not request card numbers, and we minimize customer identifiers to what a finding needs.
  • Usage and cost. Token usage and billed cost from OpenAI, Anthropic and hosting providers, per application and per day.
  • Leaked keys. When a secret key is found in an application’s public code: its kind, where it was found, the start and end of the key as your provider shows it, and a one-way hash to tell keys apart, never the key itself. With an admin key that may read it, also the name, dates and status of the matching key in your provider account, and its usage since. For OpenRouter, the key’s daily spend and credit limit. For a Supabase service-role key, the project it names. With a Stripe connection, counts and totals of failed charges, refunds, payouts and transfers since then, never a customer.
  • Errors. If you install the optional capture snippet: error messages, stack traces, page URLs and browser details, with credentials and personal data redacted at ingestion.

4. Data we collect automatically

  • No product analytics. We do not run an analytics product in the app. Nothing there records the pages you view, your approximate location, your browser or your device; the only thing counted is the daily task counts described below. The marketing site uses Cloudflare Web Analytics, which is cookieless and keeps no identifier for you, and when you sign up we store the campaign link (utm labels and referring site) that first brought you to the site, against your workspace and nothing else.
  • Task counts. How far people get through Keelnest’s own flows — setting up a first application, reviewing a proposed repair. What is stored is a daily count: which flow, which step, whether it was reached or refused, and how many times. There is no workspace, no person, no application, no address and no time finer than the day, so a count cannot be traced back to anyone, by us or by anybody else. You can turn this off for your workspace under Settings → Defaults; nothing from it is counted from then on.
  • Logs. Our hosting provider records ordinary web-server request logs — IP address, timestamp, status code — which we read for security and debugging. They are not joined to your account and nothing is built from them.
  • Google Analytics, only with your consent. When analytics is switched on for the site, the public pages may load Google Analytics. It stores nothing until you choose Accept analytics on the card that asks; choose Only essential and it counts nothing about you. Advertising features, ad personalisation and ad data sharing are off in every case. Your choice is kept for 180 days in a cookie named kn_consent; to change it, use Cookie choices in the footer of any public page, or clear that cookie, and you are asked again.
  • Cookies. A session cookie to keep you signed in and a preference cookie for theme and layout. We do not use advertising cookies or cross-site tracking.

5. The free health check

When you run the free health check we store the URL you entered, the findings, the time and a share identifier so the result can be opened by link. Checks are passive: we fetch public pages and headers as a browser would. When the site’s own public code names Supabase tables, the check asks only those tables, with the public key the site itself ships, for their row counts; it never reads a row and collects none of the data. For apps you watch, the same check asks the app’s Supabase tables for their row counts on every publish — the ones its code or your connected Supabase account names, and a few common names such as orders and payments; we keep the table names and counts, never a row and never the key. The share link contains no personal data. A result nobody claims is deleted after 30 days; one you bring into a workspace by signing up from it becomes that workspace’s first record of the app and is kept with the workspace, still opening at its link. Each check also leaves an anonymous line for our public statistics — the builder and host it recognised, which security headers were missing, whether tables could be read — with no address and nothing that identifies the site; that line is kept after the result is deleted.

6. How we protect provider credentials

Credentials are encrypted at rest with a key held only in the runtime secret store, never in the database, logs or backups in plain form. We request the narrowest scope each provider offers and use short-lived tokens where they are supported. Credentials are used only for the reads described on the security page, are redacted from every log, screenshot, trace and model prompt, and are deleted immediately when you revoke a connection, together with any webhook signing secret stored for it.

7. Why we process data and on what basis

  • To provide the service you signed up for: monitoring, verification, explanations, reports and alerts. Basis: performance of a contract.
  • To bill you and keep required financial records. Basis: contract and legal obligation.
  • To keep the service secure, prevent abuse and investigate incidents. Basis: legitimate interest.
  • To improve the product using the anonymous daily task counts described in section 4, and nothing else. Basis: legitimate interest; you can turn them off for your workspace under Settings → Defaults.
  • To send product emails about incidents, publishes and your account. Alerts are part of the service; marketing emails are sent only with consent and every one has an unsubscribe link.

8. AI explanations

When you request an explanation or a repair, or Autopilot runs one for an application whose owner turned it on, incident evidence is sent to a model provider (currently OpenAI) with secrets and personal data redacted. Providers are contractually barred from training on this data. Explanations are stored with the incident so your team can read them later.

9. Who we share data with

We share data only with processors that help us run the service, under data processing agreements, and never sell it. Current processors: Cloudflare (compute, browser rendering, network), a managed Postgres provider (database), Polar (billing), a transactional email provider (alerts and account email), and OpenAI (explanations and repairs, redacted). We disclose data to authorities only when legally required, and we tell you when we are allowed to.

10. International transfers

Our processors operate in the European Union and the United States. Where data leaves the EEA or the United Kingdom, transfers rely on standard contractual clauses or an adequacy decision. Reports are rendered in the timezone you choose, but storage location follows the processors above.

11. How long we keep data

  • Observation data, the same window on every tier: payments, AI usage and daily spend for 62 days, HTTP, SSL and header checks for 62 days, journey runs for 62 days, error events for 15 days, then deleted.
  • Failure screenshots are kept for 30 days. One attached to an incident is evidence: it is kept for as long as that incident is open, and for 30 days after it closes.
  • After each publish Keelnest reads your key public pages in a browser and keeps one sanitized screenshot of each. A reading is kept for 30 days after a newer reading of the same page replaces it; the newest one of each key page is kept, because the next publish is compared with it.
  • Workspace activity — who connected or revoked a provider, approved a repair or shared a report, and when: 365 days, then deleted.
  • The audit record — the same events seen from the other side: the role the person held at the time, the version of the record they changed, and the actions their role refused. Owners and admins read it under Organization settings. 365 days, then deleted.
  • What each AI explanation or repair cost and which workspace it was for — never the prompt or the answer: 365 days, then deleted.
  • Daily task counts — how far people get through our own flows, with no workspace or person in the count: 365 days, then deleted.
  • Pull requests and pushes read by the config check: the pull request title or the commit’s first line, the branch, the file paths and the variable, table, policy and app names in what it reported, and the verdict of the host’s preview of that commit, never the code or any value: 30 days, then deleted.
  • Rules for your AI builder written from a verified fix: fixed sentences that may name a journey, a page path, environment-variable names and table names, never a value, and which pull request carried them; kept with the incident.
  • Sign-in sessions and email verification links are deleted 7 days after they expire. An expired one is already refused everywhere; we do not keep it.
  • Account and billing records: for the life of the account, then as long as tax law requires.
  • Archiving an application keeps everything it has gathered and is reversible; it stops being watched and leaves the lists. Deleting one application is not self-serve yet: ask at privacy@keelnest.com. An owner can delete the whole workspace under Settings › General. It is deleted 7 days later with everything belonging to it, any owner can stop it until then, and we email the owners when it is done. Copies can remain in our database backups until those backups are deleted.

Once a day we count what is left in each of those windows and record the result, so a deletion that quietly stopped working is something we find rather than something you do.

12. Your rights

You can see and correct what you have given us from Settings and Account: your name, your address, your workspace, the applications you watch and the credentials you connected, which you can revoke at any time. A workspace owner can download the workspace’s apps, clients, incidents, fixes, reports and settings as one JSON file under Settings › General. It never contains passwords, keys or tokens. Checks, readings and error events are not in it; they stay in the app for the windows above. You can delete your account under Account: we email you a link, and the account is deleted when you confirm it. Your name stays on what you wrote or did in workspaces that carry on: on incident notes for as long as the incident is kept, and in the activity feed and audit record until they age out after 365 days. Polar, which handles payments, keeps the invoices tax law requires. For anything else, write to privacy@keelnest.com and we answer within 30 days. If you are in the EEA, the United Kingdom, Switzerland or a jurisdiction with similar law, you also have the right to restrict or object to processing, to portability, and to lodge a complaint with your supervisory authority. We never discriminate for exercising a right.

13. Children

The service is for businesses and is not directed at anyone under 16. We do not knowingly collect data from children; tell us if you believe we have, and we will delete it.

14. Security incidents

If a breach affects your data we notify you without undue delay, and within 72 hours where the law requires it, with what happened, what data was involved and what we are doing about it.

15. Changes to this policy

We may update this policy as the product and the law change. Material changes are announced by email and in the app at least 14 days before they take effect. The date at the top is the version in force.

16. Contact

privacy@keelnest.com for anything about this policy, security@keelnest.com for vulnerability reports.