Troubleshooting log ingest delay in Log module

Kacper — Tue, 02 Jun 2026 13:14:34 GMT

Summary

This article helps you troubleshoot situations where logs are ingested into Dynatrace later than expected when using Log module (deployed via OneAgent or Dynatrace Operator). It applies to SaaS and Managed environments and covers file-based logs, container logs, and Windows Event Logs on Linux and Windows.

Problem

You query your most recent logs and find that the latest entry is older than expected. On average, logs ingested via OneAgent are available for querying about 60 seconds after they're generated, with individual records typically arriving within a few seconds to 2 minutes. When the gap is consistently larger than this, or grows over time, the agent is falling behind.

Is this an actual ingest delay?

Two different problems can look identical at first glance. Check which one applies before continuing:

Type	What it means	Key indicator
Actual ingest delay	The agent is reading and uploading log content later than expected.	An `SFM data_loss.network` event is present, and DQL shows recent records carrying timestamps that lag behind wall-clock time.
Apparent delay (timestamp)	The agent ingests promptly, but the log lines carry old timestamps, so they appear in Dynatrace with historical timestamps.	No SFM error events; DQL shows new records arriving with consistently old embedded timestamps.

This article addresses actual ingest delay. If you're seeing an apparent delay, the issue lies in how the application or processing pipeline assigns timestamps, not in ingestion.

Troubleshooting steps

The following diagnosis applies to all three scenarios in the Resolution section.

Open the OneAgent self-monitoring dashboard in Dynatrace. It provides a per-host view of SFM events emitted by Log Module. For dashboard setup and the full list of SFM events, see OneAgent self-monitoring.
Check for data_loss.network events on the affected host. This event confirms that the agent is unable to keep up with the transmission of content.
To identify which log source is the bottleneck, compare the timestamp of the newest log entry per source in the Logs app. Sources whose most recent entry is significantly older than others are likely candidates.
Match what you observe against the scenarios below to choose a resolution.

Resolution

Too many files match a log source path pattern

Symptoms

CPU usage of the Log Analytics module is elevated.
The delay is present across multiple log sources on the same host, not just one.
The delay correlates with a custom log source whose path uses broad wildcards (for example, G:\logs\app\*\*) matching a large number of files.

Resolution

In Settings → Collect and capture → Log Monitoring → Custom log sources, take one or more of these actions:

Narrow the path pattern to exclude archived or historical files. Prefer patterns that match only actively written files.
If the application generates rotation files in the same directory, move archived logs to a separate directory and exclude that directory from the pattern.
Remove or archive old files from the monitored directory.
If the path pattern must remain broad, review whether all matched sources are still needed. Remove log ingest rules that are no longer relevant.

Log sources on network-attached storage

Symptoms

Ingest delay is present even though the number of matched files is not unusually large.
The monitored log files reside on a network share, mapped drive, or network-attached storage (NAS).
Delay tends to be more severe during periods of high network load or storage latency.

Diagnosis (additional)

To confirm the log source is on a network path, review the configured path in Settings > Collect and capture > Log Monitoring > Custom log sources and verify whether it points to a UNC path, mapped drive, or NFS/SMB mount.

Resolution

Where possible, configure the application to write logs to the local disk and monitor logs from there instead of directly from the network share.
If logs must be read from a network share, narrow the path pattern to exclude archived or historical files.
Remove or archive old files from the monitored remote directory to reduce scan overhead.

High-volume log source monopolizing the processing queue

Symptoms

Logs from most sources on a host appear on time, but one or more sources consistently show a delay.
The host has a log source with very high write rates (for example, a security event log, a verbose access log, or a high-frequency metrics log).
Processing delays for other sources grow and shrink in correlation with activity spikes on the high-volume source.

Resolution

In Settings > Collect and capture > Log Monitoring > Log ingest rules, add a rule to reduce the scope of the high-volume source. For example, filter for specific Event IDs in the Windows Security Log rather than ingesting all events.

What's next

For missing logs (records not appearing at all, not just late), see Troubleshooting missing logs.
For rotation-related gaps, see Troubleshooting log rotation issues with Log Module.
For boundary issues (multi-line entries split incorrectly, or entries merged), see Troubleshooting log record boundary detection.

article Troubleshooting log ingest delay in Log module in Troubleshooting

Troubleshooting log ingest delay in Log module

Table of contents

Summary

Problem

Is this an actual ingest delay?

Troubleshooting steps

Resolution

Too many files match a log source path pattern

Log sources on network-attached storage

High-volume log source monopolizing the processing queue

What's next