Security and data

Where SlashLog runs

• DigitalOcean, San Francisco region (SFO3), in the United States: the servers, the sign-in database and the raw archive storage.
• Logs are stored in ClickHouse on an attached storage volume; sign-in data in a managed PostgreSQL database.
• Account emails are sent through Amazon SES. Payments are handled by Stripe; we never see or store card numbers.
• The full list of service providers is in the Privacy Policy.

Encryption

• In transit: the dashboard and the ingest API are HTTPS only (TLS certificates from Let's Encrypt). Syslog can be sent over TLS; plain UDP and TCP syslog, for devices that can't do TLS, are not encrypted.
• At rest: DigitalOcean encrypts the storage volume, the managed database and object storage.
• Secrets we must use (alert webhook addresses, two-factor secrets, keys for your own archive bucket) are encrypted in our database. Secrets we only check (passwords, ingest tokens, recovery codes) are stored only as hashes and can't be read back, even by us.

Masking: what it covers and what it doesn't

Masking runs in the ingest service, before a log is queued, so a masked value is never stored, archived, shown in live tail or sent to an alert.

• On by default: payment card numbers and secrets (passwords and tokens in key=value form, API keys from common providers, JWTs, private keys).
• Opt in: US Social Security numbers, emails, phone numbers, IP addresses, and your own patterns. Emails, phones and IPs can be hashed instead of removed, so you can still group and search by a value you already know.
• Where it looks: the message and every text value in the log's structured fields, at any depth.

It does not catch:

• Values in field names, or in the service name.
• Values sent as JSON numbers rather than text (for example a card number as a number).
• Encoded values: base64, URL-encoded or hex-encoded secrets look like ordinary text.
• Secrets in a format it doesn't know. Add a custom pattern for those, and test it on the Privacy page.

Masking is a safety net, not a guarantee. The safest secret is one your code never logs.

Who can see your data

• Your workspace's members, by role: admins manage destinations, tokens, masking and members, and delete logs; members search, tail and manage rules.
• Nobody in another workspace. Every query is limited to the signed-in workspace on the server, and automated checks run on every change to make sure no query can reach another workspace's logs.
• SlashLog's operator has administrative access to the servers to run the service and looks at customer logs only to fix a problem you report, or when the law requires it.

Two-factor sign-in (authenticator app and recovery codes) is available to everyone. Changes to a workspace and sign-ins are recorded in its Activity log for a year, visible to admins.

Retention and deletion

Logs are deleted automatically after your plan's search period:

• Logs your rules drop are kept briefly (24 hours to 7 days, by plan) so you can check or restore them, then deleted.
• You can delete stored logs yourself from the Logs page, at any time.
• Deleting a workspace or account stops new logs at once; everything is erased 30 days later, so a mistake, or an intruder, can be undone. Email support@slashlog.dev to have it erased sooner.
• Files in your own archive bucket are yours: we never delete them.

Backups and availability

• Settings (rules, destinations, masking, templates, usage) are backed up daily; the sign-in database daily.
• Stored logs are not backed up. If you need a durable copy, turn on the raw archive (Archive page): every log as it arrived, after masking, written every 10 minutes, to our storage or to your own bucket.
• SlashLog runs on a single server today. If it's down, logs sent by Vector, rsyslog or another agent with a buffer are retried when it's back; logs sent straight from your code without retries can be lost.
• Uptime and incidents are public at status.slashlog.dev.

What we don't have yet

• No SOC 2 or ISO 27001 report.
• No data processing agreement (DPA) to sign, and no EU or UK data location.
• No single sign-on (SAML) yet.

If one of these is a requirement for you, tell us at support@slashlog.dev: it helps us decide what comes next.

Reporting a security issue

Email support@slashlog.dev with "Security" in the subject. We'll reply within two business days and keep you posted until it's fixed. Please don't access other people's data or disrupt the service while testing.