Limits
Request sizes, rate limits, backpressure and how levels are mapped.
This page lists the limits that apply to every ingestion method, and how dlogify reads log levels.
Request limits
| Limit | Value | When exceeded |
|---|---|---|
| Request body, after decompression | 1 MB | 413 payload-too-large |
| Events per request | 1,000 | 413 payload-too-large |
message | 16 KB | Cut; the event is flagged as truncated |
stack_trace | 40 KB | Cut; the event is flagged as truncated |
| Attributes, all together | 8 KB | Cut; the event is flagged as truncated |
| Time to send the whole request | 30 seconds | 408, connection closed |
Only gzip and no encoding are accepted (unsupported-encoding).
Rate limits and quotas
Each organization has a number of events per minute and per month, set by its plan (see Plans and usage). Going over either returns 429 rate-limited with a Retry-After header; the monthly quota resets at the start of the next month (UTC). Responses carry RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset.
Backpressure
When dlogify cannot accept more data for a moment, it answers 429 with Retry-After instead of losing it. Retry after the indicated time, with backoff, and keep the data buffered meanwhile. The dlogify clients and the OpenTelemetry exporters do this for you.
Level mapping
dlogify works with three levels. Incoming levels map to them like this:
REST level or OTLP severity_text | OTLP severity_number | dlogify level |
|---|---|---|
trace, debug | 1–8 | Dropped |
info, notice | 9–12 | INFO |
warn, warning | 13–16 | WARN |
error | 17–20 | ERROR |
fatal, critical, emergency, alert | 21–24 | ERROR, marked fatal |
| missing or unknown | 0 | INFO, marked as inferred |
ERROR and WARN events are grouped into error groups and can produce tickets. INFO events are counted and summarized.