Legal
Data Retention Policy
Last updated October 3, 2026 · Operated by Pimzee LLC
1. Our approach
dlogify is built to keep as little of your log data as it can, for as short a time as it can. This policy is part of the Terms of Service and the Privacy Policy of Pimzee LLC.
2. What we never access
dlogify only processes the events that your applications or collectors send to it with an API key. It never connects to your servers, databases, source code, cloud accounts or internal services, and it cannot read anything you do not send. An API key can only send events; it cannot read data or manage your account.
3. What we do not keep
We do not keep a copy of your log stream:
- INFO events are not stored one by one. They are counted per time window, with at most 3 redacted example lines per message pattern.
- TRACE and DEBUG events are never stored. The last 50 lines of each stream are held in memory only, to give context to an error, and are lost when the service restarts.
- Of ERROR and WARN events, we keep at most 10 redacted samples per error group, each with up to 30 redacted surrounding lines.
- Passwords and API keys are stored only as hashes. Webhook signing secrets are stored encrypted.
4. Redaction before storage
Before an event is stored or sent to any provider, its message, stack trace and attributes are redacted. The following values are replaced by a marker such as <email> or <secret>:
- email addresses;
- payment card numbers;
- IP addresses;
- JSON Web Tokens, bearer tokens and keys with well-known prefixes, such as Stripe, GitHub, GitLab, Slack, AWS and Google keys;
- values that follow password, secret, token, api_key or access_key;
- the whole value of attributes named like password, secret, token, authorization, cookie, api_key or session.
Redaction is automated and works by recognizing patterns. It is designed to remove personal and secret values, but it cannot recognize every format, such as names, postal addresses or secrets with an unknown shape. Do not log passwords, secrets, payment card data, health information or other sensitive data: you are responsible for what your applications send.
5. Retention periods
| Data | Kept for |
|---|---|
| Incoming event batches, before processing | Until processed, usually a few seconds. They are held in an internal queue and are not yet redacted. |
| Event batches that fail processing | At most 14 days in an internal error queue, so that the failure can be fixed; then deleted automatically. |
| Error samples, tickets, INFO summaries and digests | 7 days on Free, 30 days on Pro, 90 days on Team. |
| INFO counts | Only the current and the previous time window. |
| Error groups: redacted message pattern, counters, first and last seen | As long as the project exists. |
| Records used to discard duplicate deliveries (no log content) | 24 hours. |
| Account, organization and project information | Until you ask us to delete it; deleted within 30 days of the request. |
| Billing records | As long as tax and accounting laws require. |
Retention is applied automatically every hour, using the current plan of each organization. After a move to a plan with shorter retention, older data is deleted at the next run.
6. AI providers
To classify errors and write tickets and summaries, we send redacted excerpts to the AI providers listed in the Privacy Policy, never full log streams. Requests are made with settings that disable training on the data and, where the provider offers it, storage of the request. What the providers retain is governed by their own terms.
7. Deletion on request
An owner can ask us to delete a project, an organization or an account by writing to [email protected] from the owner's email address. We delete the data within 30 days of the request. To stop sending data at once, revoke the project's API keys in the dashboard.
8. Contact
Questions about this policy: Pimzee LLC, [email protected].