Back home

Data security

What we do to protect accounts, monitors and check history. No marketing promises — concrete on every point.

We don't sell data

To anyone. Ever. Email addresses and monitor URLs are for providing the service, not for ads or resale.

No third-party trackers in the app

There's no analytics or third-party scripts in the dashboard or admin panel. They're only on the public pages of the site (Yandex.Metrika for traffic estimation).

152-FZ compliance

Personal data processing is described in the Privacy Policy. Any user can request an export, change or deletion of their data.

Channel encryption

All traffic between the browser, the bot and our API goes over TLS 1.2/1.3. Certificates renew automatically — you won't see an expired SSL on our side.

  • HTTPS enforced — HTTP requests are redirected
  • Modern cipher suites, no legacy algorithms
  • HSTS — the browser remembers the site is HTTPS-only

Password storage

Passwords are never stored in plain text. We use bcrypt — an industry standard with adjustable cost. Recovering the original password from the database is impossible, even for service staff.

  • bcrypt with a current cost factor
  • Minimum length 8 + a requirement for different character types
  • Live strength check on registration and reset

Brute-force protection

Login, registration and password-reset attempts are limited per IP and by an overall cap. Password guessing or mass email harvesting becomes impractical even with automation.

  • Login attempts: 5 per minute, 30 per hour from one IP
  • Registration: 3 per minute, 10 per hour
  • Honeypot and time-to-submit on forms — filter out naive bots
  • Generic forgot-password responses — you can't tell from the reply whether an email is registered

Email verification

All email addresses are verified via a link. An account without a verified email won't get critical notifications — this protects against signing up with someone else's mailbox.

  • One-time confirmation tokens
  • Protection against token reuse
  • A dashboard banner reminds you to verify

Backups

The database is backed up regularly. Backups are stored separately from the main infrastructure and tested for recoverability.

  • Daily DB backups
  • Several generations kept (in case a problem isn't noticed immediately)
  • Periodic restore tests

Logging and audit

Administrator actions and important system events are logged with the user, IP and time. This makes it possible to investigate incidents and spot anomalies.

  • Audit log of admin actions: blocking, granting Premium, deletion
  • Logs survive deploys — they aren't reset on update
  • Structured logs with filters by component and level

Service isolation

The service's components run in separate Docker containers with minimal privileges. Agents on user VPS use a pull model — we don't open inbound ports on your server.

  • Containers run as a non-root user
  • Internal traffic over a private network, only nginx exposed outward
  • Monitoring agents only initiate outbound connections

Monitoring ourselves

We use UptimeDog to monitor UptimeDog. If the main service goes down, we find out first, and it's visible on the public status page.

  • A separate monitoring instance for production infrastructure
  • A public status page available to everyone
  • Alerts to the team's on-call channel

Found a vulnerability?

If you've found a security issue — please don't publish it before we've had a chance to fix it. Write directly and we'll respond promptly. Responsible disclosure is rewarded with a mention in credits (if you'd like).

Report via email