Security

Security at Simrix Monitor

Effective September 29, 2026

What Simrix Monitor reaches, what it keeps, how long it keeps it, and who else touches it. Written against the code rather than from a template, and it says what we have not built as clearly as what we have.

What we access

A check opens pages in a real browser from our infrastructure. It reaches the URL you give it and whatever that page loads, exactly as a visitor’s browser would. Nothing is installed on your site.

Two kinds of address are refused outright. Anything that is not http or https, and any host that names a private or internal network, which covers localhost, the private IPv4 ranges, link-local addresses and IPv6 loopback and unique-local addresses. A workspace can also keep its own blocklist, and a check against a blocked address is recorded as failed without a browser ever starting.

Checks never sign in. There is no credential store, no login step and no session to reuse. Every check starts from a logged-out browser. A monitor can confirm that your sign-in page loads and its form is present, which is a different and much weaker thing than signing in, and we describe it that way everywhere.

If you build a monitor that types into a field, the value you enter is saved as part of that monitor’s configuration in plain text, and it can appear in the diagnostics we generate when that step fails. Do not put a password, card number or other secret into a monitor. Monitors are for public journeys.

When you pick a region of a page to watch, we check it against patterns for password fields, payment fields, personal data, admin areas and explicit content. Today a match is flagged for review, not blocked. It is recorded against the monitor and surfaced internally. We would rather tell you that than let you assume a block exists.

What we store

For each check we keep:

  • Screenshots. The page at the moment of the check, the previous baseline for comparison, and a highlighted image of the differences.
  • Extracted page text. The readable text of the page or the region you selected, before and after, so a change can be described. We do not store the page’s HTML.
  • A fingerprint of that text, used to tell a real change from a re-render.
  • The result. Pass or fail, duration, response code, the final address, the failure reason, and the plain-English summary shown in alerts.
  • The monitor’s own configuration, including the address it starts from and the steps it follows.

For your account we keep your email address, your name if you gave one, your workspace name, and billing identifiers from our payment provider. We do not hold your card details at any point.

How long we keep it

  • Screenshots and difference images: 7 days. After that they are removed and the check record keeps a reference that no longer resolves.
  • Picker previews: 12 hours. These are the temporary captures made while you are choosing a region to watch.
  • Extracted page text: 7 days. The same window as the screenshots it was captured beside. One exception, and it is deliberate: the most recent text we hold for a monitor is what the next check compares against, so that one is kept until a newer check replaces it. On a monitor that checks monthly, that means one page of text for a month.
  • Check records: kept until you ask us to remove them. The status, timing, summary and change verdict of every check stay; that is your monitoring history. It is the raw page text above that ages out of it.

Retention is the same on every plan. It is not something you can buy more or less of today.

How your data is protected

In transit. The site is served over HTTPS and sends a strict transport security header, so a browser that has seen the site once will refuse to connect over plain HTTP afterwards. We also set a content security policy and the usual protections against content-type sniffing, framing and referrer leakage.

Screenshots are not public. They are not served from a public bucket and do not have guessable links. Every request goes through an endpoint that requires you to be signed in and to be a member of the workspace that owns the image, and it answers a non-member as if the file does not exist. A link copied out of the app will not open for anyone outside your workspace.

Passwords are hashed with scrypt and a per-account random salt, and compared in constant time. We never store the password itself.

API keys are stored only as a SHA-256 hash alongside a short prefix for display. The full key is shown once, when it is created, and cannot be recovered afterwards.

At rest, data is protected by the encryption our database and object storage providers apply. Simrix Monitor does not add a second layer of application-level encryption on top, and we would rather say so than imply otherwise.

Who else touches your data

These are the third parties that process customer data on our behalf. Each one receives only what the feature needs.

  • Railway. Application hosting and the PostgreSQL database holding all account and monitoring data
  • Cloudflare (R2). Object storage for screenshots
  • Stripe. Subscription billing and payment processing
  • Resend. Transactional and alert email delivery
  • OpenAI. Generating change summaries and failure explanations, suggesting monitors during setup, answering questions in MonitorBot, sorting support requests, and finding a product page during the free Checkout Health Check
  • Sentry. Application error monitoring
  • Google. Optional sign-in with a Google account
  • Google (Analytics). Visit and campaign measurement on the public website only, with ad personalisation and Google Signals off, and only with your consent where a consent banner is shown
  • Google (Ads). Counting which of our ads led to a sign-up or a free check, on the public website only; its cookies are set only while marketing cookies are on (in Europe only if you accept them, elsewhere unless you turn them off), and ad personalisation is off
  • OpenAI (ChatGPT ads). Counting which of our ads in ChatGPT led to a sign-up or a free check, on the public website only, matched by a one-way code made in your browser from the email address or name entered in our forms; its pixel loads only while marketing cookies are on (in Europe only if you accept them, elsewhere unless you turn them off), and every event asks OpenAI not to use it for personalisation
  • Cookiebot (Usercentrics). The consent banner on the public website, shown to visitors whose IP address places them in Europe, and the record of the choice made in it

Two things worth being specific about. Our AI provider receives the text of the page region that changed, truncated, along with the monitor’s name and address, in order to describe the change. When a check fails, it also receives the failure details and the step that failed. Our email provider receives the recipient address and the alert itself, which includes a short extract of the page text and a link to the evidence.

Our hosting and database providers necessarily hold everything. They are described in the Privacy Policy rather than named individually here.

Reporting a vulnerability

Email [email protected] with enough detail to reproduce the issue. Please include the affected address, the steps you took and what you observed.

We will acknowledge your report and tell you what we find. Please give us a reasonable opportunity to fix an issue before describing it publicly, and please do not access another customer’s data, degrade the service, or run automated scanning against it while testing.

We do not operate a paid bug bounty. We are a small team and we will say plainly whether something is fixed, planned, or accepted as-is.

Deleting your data

Deleting a monitor removes its checks and their evidence. Deleting a site removes the monitors under it.

You can delete a workspace yourself. An owner will find it under Account → Account profile. It removes the workspace and everything in it (sites, monitors, check history, API keys and webhooks) and cancels the subscription first, so a failure to cancel stops the deletion rather than leaving you paying for something that no longer exists. Anyone on the team who belongs to no other workspace has their account removed with it. It is immediate and we cannot undo it.

Two things outlive it. Screenshots already in object storage age out on their own schedule rather than being removed at that moment, and we keep what we are required to keep for tax and accounting. If you would rather we handled it, email [email protected] from the address on the account.

You can ask for a copy of your data at the same address. See the Privacy Policy for the full set of rights.

What we have not built

A security page that lists only strengths is not much use. These are the things we are asked for and do not have today.

  • No single sign-on, SCIM, or enforced two-factor authentication. Sign-in is Google or email and password.
  • No self-service data export. Deletion is self-service; export is still handled by email, as above.
  • No configurable retention. The windows above apply to everyone.
  • No independent security certification. We have not completed SOC 2 or ISO 27001 and do not claim to be working toward either on a published timeline.
  • A limited audit log. Paid plans can read the fifty most recent settings, billing and membership changes for the workspace they are in, with who made each one, under Account › Audit log. It is not exportable, it does not cover every internal action, and Free does not include it.

If one of these is a blocker for you, say so when you get in touch. It is useful for us to know which ones people actually need.

See also our Terms of Service, Privacy Policy and Data Processing Agreement.