Act

Log forwarding

Log forwarding sends the logs MonitOps receives on to a log platform or SIEM that you operate. It uses OTLP, delivers only masked and normalised records, and gives each destination its own persistent queue.

How it works#

Egress is a configurable fan-out. You define destinations, and routing rules choose which sources and signals go to each one.

What is forwarded#

Property	Behaviour
Content	Records after masking and after normalisation. There is no separate unmasked path
Sampling	Forwarded logs are not sampled
Selection	Routing rules by source and signal, per destination
Source policy	Each source carries a forwarding policy that its sender cannot override

A source that belongs outside your own estate, such as an external collector, is not forwarded by default (see Sources). Sources of your own estate are forwarded by default.

What is never forwarded#

Unmasked records. Mandatory masking runs before any forwarding and cannot be removed or bypassed (see Masking).
Records outside a destination's routing rules: a destination receives only what its rules select.

Queue, retries and backlog#

Each destination has its own persistent queue with retries.

A slow or unavailable destination does not block the others and does not block ingestion.
Delivery resumes from the queue when the destination returns.
The queue's capacity, disk budget, retry retention and overflow behaviour are configured.
When the queue saturates, the destination shows saturation rather than claiming that nothing can be lost.
After an outage, replayed records can arrive more than once. Replay duplicates are reported separately from loss.

Forwarding-failure alert#

A state rule raises a major alert when forwarding failures persist for two consecutive minutes, by default. It follows the normal alert path into incidents, so a failing log destination is visible like any other problem (see Alarm definitions).

SIEM#

A SIEM destination receives security-relevant events in the format the SIEM expects, through its forwarder or over syslog. Planned events cover application audit events and node and platform audit logs.

Configuration#

Open Destinations and add a destination of kind Log platform or SIEM.
Enter the OTLP endpoint and its authentication.
Add routing rules that choose the sources and signals the destination receives.
Set the queue capacity and overflow behaviour.
Check the destination's backlog and freshness once data is flowing.

What you see in the console#

The destinations page shows each log destination with its routing rules, backlog, errors and freshness. Forwarding failures that persist appear as an alert and an incident like any other.

Limits and defaults#

Forwarded logs are post-masking and post-normalisation, and unsampled.
Each destination has its own queue.
Forwarding-failure alert: two consecutive minutes of failures, major.
Queue capacity and overflow behaviour are configured per destination.

Failure states#

State	What the console shows
Destination slow or down	Backlog grows on that destination only
Queue saturated	A saturation state on the destination
Delivery errors	Error count and last error
Persistent forwarding failure	A major alert that can group into an incident

Last updated October 2026