Ingestion and Upload Limits

Telebugs applies fixed safety limits to each new error report, envelope, artifact, and artifact bundle. These boundaries keep memory, CPU, disk, SQLite, and the job queue predictable on a small self-hosted server.

The limits are per object, not account quotas. They do not restrict how many projects, releases, or error reports you can keep. They are intentionally not configurable: an operator cannot accidentally remove the safety boundary while trying to fix an unrelated capacity problem.

Event Requests

Telebugs accepts uncompressed requests and requests using gzip or zlib-wrapped deflate. Encoding names are case-insensitive. Brotli, Zstandard, and requests with more than one content encoding are not supported.

Telebugs rejects a request before durable acceptance when its wire or decoded body, framing, JSON, or binary item cannot be handled safely. A valid envelope with no supported event is acknowledged but is not added to the processing queue. An empty request body remains a successful no-op.

Event Details Retained

Large but valid event collections are handled differently from an oversized request. Telebugs accepts the event and deterministically keeps the most useful subset:

Tag keys are limited to 200 bytes and tag values to 2 KiB. Telebugs preserves the input order of retained entries and shortens strings only at valid UTF-8 boundaries. Grouping and persistence use the same normalized event, so sending the same oversized event repeatedly still produces stable grouping.

Ingestion Warning

When Telebugs shortens strings or leaves collection entries out, the report page shows an Ingestion warning above the report details. The warning means the error was accepted, but some diagnostic detail exceeded a safety boundary. It names the affected sections and shows how many entries were omitted or strings were shortened.

The same bounded summary is included when you use View as:

• JSON: details.ingest_truncations
• XML: <ingest_truncations>
• Markdown: an Ingestion warning section

The warning does not indicate a broken SDK or failed report. If the omitted details are important, reduce noisy breadcrumbs, repeated frames, oversized custom context, or other high-volume event data at the SDK.

Pending Event Queue

Telebugs pauses new event intake when pending decoded payloads reach 512 MiB, even if the configurable queued-error count check is disabled. The existing queued-error count limit remains configurable and defaults to 10,000.

Open Instance > Ingest Protection to see:

• queued errors;
• queued payload bytes;
• the fixed queued-byte ceiling;
• bounded-ingest rejections in the last hour;
• truncated events in the last hour.

The queued-byte ceiling is read-only. It bounds memory, disk, and drain-time exposure without adding another setting that operators must tune.

Artifact and Source Map Uploads

The following limits apply to new release artifacts, source maps, chunks, and ZIP bundles:

Telebugs counts ZIP entries and expanded bytes while reading them instead of trusting archive metadata. It rejects path traversal, absolute paths, backslashes, invalid UTF-8, NUL bytes, duplicate paths, ambiguous manifest matches, encrypted entries, links, devices, CRC errors, and inconsistent size metadata. A ZIP file stored inside a bundle is ordinary artifact content; it is not recursively expanded.

Existing stored artifacts remain readable even when they are larger than a new upload limit.

Reuploads and Conflicts

Uploading identical bytes to the same artifact name and release is idempotent. Telebugs returns the existing artifact instead of storing a duplicate.

Uploading different bytes to an existing name in the same release returns 409 Conflict. An artifact-bundle conflict aborts the entire bundle, so a release is never left half-updated. Delete the incorrect artifact deliberately or publish the new content under the correct release version.

Modern Sentry CLI clients use artifact bundles. Legacy 2.x clients can use the direct release-file API. Telebugs has compatibility coverage for both Sentry CLI 2.58.6 and 3.6.2. See Source Maps for setup and upload commands.

HTTP Responses and Retries

Permanent event-ingestion failures include an X-Sentry-Error reason and no retry header. A 429 response includes Retry-After and X-Sentry-Rate-Limits. Sentry SDKs should drop permanent 400, 413, and 415 responses, while retrying 429 and transient 5xx responses.

Troubleshooting

• For repeated 413 responses, reduce one event, attachment, minidump, source map, artifact, or archive. Retrying identical bytes cannot succeed.
• For 415, remove multiple encodings or use identity, gzip, or deflate.
• For 429, check Instance > Ingest Protection. Let the queue drain, restore free disk space, or wait for the rate window before retrying.
• For artifact 409, verify the release version and artifact name. Do not overwrite a source map from an already-published release accidentally.
• If queued payload bytes remain high, inspect the Jobs dashboard and SQLite/Active Storage errors before increasing worker concurrency.
• If bundle assembly reports disk pressure, restore at least the configured free-disk floor plus 384 MiB of scratch space.

These fixed limits are safety boundaries for individual objects. Use retention policies and ingest protection for long-term storage and traffic management.