Useful analytics starts with clear boundaries.
Control who reaches a project, how activity is collected and what leaves it. Every practice below is one the product enforces today — and a list at the end says what we don't claim.
Keys · Online store
Sample data-
sg2_ingest_4f…Send events used 2 min ago -
sg2_read_91…Read stats used yesterday -
sg2_admin_c0…Manage project never used
A secret is shown once, then stored hashed.
Audit trail
- Ana revoked a read key 12:41
- Deniz required two-factor 11:02
- Ana created a share link 09:15
In place today
Ten practices, each one enforced by the product.
If the product doesn't enforce a practice today, it doesn't go on this page.
-
Public pages carry aggregates only
A shared dashboard, board, report or map shows numbers, labels and country totals. An automated check opens every public page with real project, organization and link identifiers, e-mails, names and key secrets behind it, and fails if any of them appears.
-
The analytics store is read-only from the app
Every screen reads measurements with an account that can only read, and a readiness check tries to write and expects the refusal. Only the collection service ever writes an event.
-
Every query is scoped
A question reaches your measurements only when it names one project, or one organization's own projects; anything else is refused, and nothing a visitor types is ever pasted into a query.
-
Secrets are shown once and stored hashed
An API key and a public link are shown the moment they are made and stored only as a hash; the install key is sealed for its organization. Revoking a key tells the collection service in the same step that revokes it.
-
Two-factor authentication; staff must enrol
Time-based one-time codes with QR enrolment, single-use recovery codes, and password confirmation before a sensitive change. Staff who can reach the console must have a second factor.
-
Accounts open by invitation
Self-serve registration is closed in production. A signed invitation from the waitlist opens registration for one address for seven days, and a readiness check warns when the door is open.
-
An audit trail on both sides
Every change to a project, a key, a plan or an organization is recorded by the analytics service with who did it, and by the application in its own activity log. Administrators read both side by side.
-
Production data cannot be wiped by a command
Commands that drop or rebuild a database are refused everywhere except a developer's own machine, and an automated check keeps that guard in place.
-
Dependencies with advisories refused
A third-party library with a published security advisory cannot be installed, and front-end packages install in a locked-down environment with an audit after every install.
-
A readiness gate before a deploy
Sixty-seven checks run before a release and again on the server afterwards. They read settings and never change anything, and each failure names its exact remedy.
Not claimed
What this page does not certify.
An absence you'd assume is filled is worse than one we name. None of these is held or promised today.
-
No certification
No SOC 2, ISO 27001 or other compliance certificate is held — so no badge is shown.
-
No uptime commitment
The status page reports what was measured — reachability from outside this deployment, and four services from inside it. No availability target is promised, and no credit is owed if one is missed.
-
No penetration-test result
None has been commissioned yet.
-
No data-residency guarantee
This page names no hosting region.
-
No support or incident commitment
No response time or incident-response promise has been made.
Found something? Tell us first.
Use Contact for a security question and ask for a safer channel. Leave credentials, personal records and exploit details out of an ordinary message.
Accounts open by invitation
See your traffic honestly. Ask for your invitation.
Join the waitlist. When we invite you, connect a site, app, or server and start reading.
A site, an app, or a server · No cookies · Public links show totals