Privacy

Notarus exists to carry the context of a bug report. That means it captures more than a contact form does, so this page is specific about what it takes, what it refuses to take, and how long it keeps it.

Who this describes

Two groups of people meet here. Customers are the teams who install Notarus on their site and use the panel. Reporters are their end users — the people who click the widget and send feedback. A customer decides what runs on their site; this page describes what the software does when they do.

What the widget collects

• The feedback itself: the message, the type, and anything the reporter chose to attach.
• A screenshot of the page, taken on the reporter's device and only when they take one.
• Technical context: page URL, browser and operating system, viewport size, and console and network metadata.
• Session events — clicks, scrolls, navigation and page snapshots — when session replay is enabled for the project.
• A screen or camera recording, only when the reporter starts one.

What it never collects

These are properties of the code, not policies applied afterwards.

• Request and response bodies are never captured. Network activity is recorded as metadata — method, URL, status, timing — and the payload is never read.
• Typed input is masked in replays, always. Replay records that a field was typed into, never what was typed. This cannot be turned off.
• Secret-looking keys are redacted before storage. Any key matching authorization, cookie, password, token, secret, api key or assertion is replaced with [redacted]. A project can add its own keywords to that list; it cannot remove any.

IP addresses

A reporter's IP address is never stored. It is passed through a one-way salted hash and truncated, which is enough to tell two sessions apart and not enough to recover the address. A project can switch that off entirely, in which case nothing derived from the IP is stored at all.

Where the data lives

Relational data — accounts, projects, tickets, sessions — is stored in a managed PostgreSQL database. Uploaded media (screenshots, recordings, replay assets) is stored on edge storage and served through a CDN using signed, expiring URLs, so a media link is not a permanent public address.

How long it is kept

• Console and network logs: 30 days, then deleted by a nightly job.
• Idle sessions: 90 days.
• Recordings: until their configured expiry, then purged.
• Tickets: kept until the project or the account is deleted. A ticket is the work item; it does not expire on a timer.

Deleting a project deletes its tickets, sessions and media. Deleting an account deletes its projects.

Who can see it

Access is scoped per project and per role, and enforced in one place that both the panel and the MCP server call. Every table in the database additionally denies access by default at the row level, and the database's own public REST API is switched off — the application server is the only door.

Other services

Payment details are handled by Stripe and never reach Notarus's servers. When a customer connects an integration — Slack, Microsoft Teams, Jira, Linear, GitHub, Trello, Asana, ClickUp or monday.com — ticket content is sent to that service on their instruction. No integration is connected by default.

Questions and requests

For access, correction or deletion of data held about you: if you reported feedback through a widget, the team who runs that site is your first contact, since the project is theirs. If you hold a Notarus account, contact the operator of the instance you signed up to.