Ingest priority
Not every log is equally urgent. Mark your security logs Critical and your debug or bulk logs Low. When storage gets busy, LogPulse turns Low away first and keeps taking Critical, so your detections keep running.
Overview
Every event gets one of three priorities. LogPulse watches how busy storage is and gives the environment a status: Normal, Under pressure or Protecting storage. The status decides which priorities are accepted. Nothing is sampled or thrown away silently: a refused request gets an answer that tells the sender to retry later.
Durable ingest buffer
By default every accepted log first lands in a durable buffer and is stored from there. If storage slows down, logs wait in the buffer instead of being lost, and Normal traffic keeps being accepted. The same buffer keeps the original logs of the last hour for raw replay.
Priorities
| Priority | Use it for | Behaviour |
|---|---|---|
| Critical | Security logs: authentication, firewall, EDR, audit trails | Has its own lane and is stored first. Accepted at every status |
| Normal | Everything else (default) | Refused only when storage is protected |
| Low | Debug logs, bulk imports, verbose application logs | Refused first, as soon as storage is under pressure |
Set a priority
Go to Sources → Ingest priority. The main table lists every index, each Normal by default. Change a row to Critical or Low. Below it you can also set a priority per sourcetype, per API key and per agent group. Only owners and admins can change priorities.
Which priority wins
When more than one rule applies to an event, the most specific one wins:
sourcetype > index > API key > agent group > NormalA sourcetype rule applies in every index. So sourcetype=windows:security set to Critical stays Critical, even in an index that is set to Low.
Storage status
The status is shown on the Ingest priority page.
| Status | Accepted | Refused |
|---|---|---|
| Normal | Critical, Normal, Low | Nothing |
| Under pressure | Critical, Normal | Low |
| Protecting storage | Critical | Normal and Low |
Slow storage alone gives Under pressure: the buffer absorbs the delay. Protecting storage only comes when the backlog in the buffer gets close to its retention, by default after six hours of backlog. The status goes up at once and comes down one step at a time, each step after at least 60 seconds of calm. If the status cannot be read, LogPulse accepts everything.
X-LogPulse-Overloaded.What a sender gets back
| Situation | Response |
|---|---|
| All events accepted | 200 |
| Some events refused (a batch with several indexes) | 207 with the number of refused events in X-LogPulse-Refused-Events and a Retry-After |
| All events refused | 429 with Retry-After |
| API instance overloaded | 429 with X-LogPulse-Overloaded and Retry-After of 5 or 10 seconds |
| An event larger than 256 KB | Accepted but cut off. Header X-LogPulse-Truncated-Events and truncatedEvents in the body |
Agents and collectors
The LogPulse agent, Fluent Bit and the OpenTelemetry collector respect 429 and Retry-After: they keep the logs and send them again later. Use a sender that does the same if you write your own, see HTTP API.
Critical limit per plan
On shared environments, Critical has a limit per organization so one customer cannot claim the whole priority lane. Events above the limit are handled as Normal, not refused, and the response says how many in the header X-LogPulse-Critical-Demoted.
| Plan | Critical events per minute |
|---|---|
| Free | 600 |
| Starter | 3,000 |
| Pro | 15,000 |
| Business | 60,000 |
| Dedicated environment | No limit |
API
| Call | What it does |
|---|---|
GET /api/v1/ingest-priority | Current rules, API keys, agent groups, and the storage status with its reasons |
PUT /api/v1/ingest-priority/rules | Set the rules per index and sourcetype |
PUT /api/v1/ingest-priority/api-keys/:id | Set the priority of one API key |
PUT /api/v1/ingest-priority/agent-groups/:id | Set the priority of one agent group |
Reading needs settings:read, changing needs settings:update.