Skip to content

Usage, limits and data retention

What counts toward the plan, what happens at a limit or at the end of the trial, and how long PostDeploy keeps your data.

What counts

Each organization can store 1 million error events and 100 GB of logs per calendar month (UTC).

Log usage counts the bytes of each accepted log entry once.

Items that your filters or sampling refuse do not count toward usage.

Owners and admins set those filters on the Data controls settings page: extra sensitive field names, stored log levels, excluded exception types, and error and log sampling.

The billing page and the get_usage MCP tool show this month's usage against each allowance.

At a limit

When an allowance is used up, ingestion answers 429 with Retry-After until the next month starts, and stores nothing from that request.

Owners get an email when usage reaches 70%, 90% and 100% of an allowance.

Each organization also has a request rate limit. Over it, ingestion answers 429 rate_limited with Retry-After.

After the trial

When the trial ends without a subscription, ingestion answers 429 subscription_required. Stored errors and logs stay readable until they expire.

Subscribing from the billing page starts ingestion again for the same organization.

Retention

Errors are kept 90 days from the time PostDeploy receives them.

Logs are kept 90 days from the time PostDeploy receives them, even when the log entry carries an older timestamp.

Searches and agent tools do not return data past retention, even before the deletion job removes it.

Where data is stored

Each organization has its own SQLite database on the server. Error payloads are stored in Cloudflare R2 before ingestion answers success.

If R2 is unreachable, PostDeploy stores no error events and answers 503 ingest_unavailable. Whether the event is sent again depends on the SDK.

A success response means the logs are committed to the server's SQLite database. They survive a server restart before they reach R2.

The server writes log batches to R2 within five minutes when R2 is reachable. Logs that are not yet in R2 are lost if the server's disk is lost.

If R2 is unreachable, logs stay in SQLite and stay searchable. When an organization's unarchived logs reach the backlog limit, ingestion answers 503 log_backlog_full until archiving catches up.

A log search reads a bounded part of the history per request. When the response sets coverage.truncated_by, pass next as before to continue further back.

Backups

The server writes encrypted backup sets of every organization database to R2.

A restore task rebuilds the databases from one backup set while the server is stopped.

Backup sets keep copies of deleted and expired data for 14 days. The first successful backup after that deletes them.