When data is missing

Choose your symptom

Start with the closest match, then follow the checks in order.

Check the server and agent first

Problem: LogForge will not open, an agent is disconnected, or workload data is missing.

Why it matters: running containers do not prove discovery, collection, or saved queries work.

Next step: use Bash on the server's Linux host, with Docker access, inside your existing installation directory.

For an online installation, inspect docker compose logs storage-init in the clone if initialization failed. Once initialized, check the services with its generated runtime commands. After a product update, use the recorded updater start/recovery controls. Keep an older installation on the procedure in its own README.

For the signed air-gapped package:

./unicron status
./unicron logs

Use the commands for your installation method; do not mix Compose settings with the signed package launcher.

1. Check the LogForge server stays running. Read logs privately and redact before sharing.
2. If LogForge still will not open, check its configured browser address, network access, and certificate trust using Networking and certificates. Continue once you can sign in.
3. In LogForge, open Overview > Hosts. Check agent connectivity and inventory freshness.
4. For another Docker host, check both agent connection addresses from that host. Browser access tests a different path; see Networking.

Preserve state: investigate the existing agent before recreating it or deleting data.

Workload is missing

• Check the application runs on the agent's Docker daemon.
• Check runtime permissions and current inventory. Disconnected/stale agents cannot supply fresh discovery.
• For Business Members, check effective environment access. Do not broaden access merely to test collection.

Logs are empty

1. Confirm Monitor logs and alerts is on and finished applying.
2. Clear Search logs, Severity, and Advanced filters. Broaden Time range.
3. Produce a harmless event known to write to standard output/error.
4. Read Health and any Collection needs attention reason.
5. Check readable Docker json-file logs. For Docker with a custom data root, obtain release-specific guidance; a shell variable does not override the generated Compose installer. If your application forwards logs using the Forward protocol, its configured route must reach host loopback port 24224.

Live only · Not retained: those rows are not saved. Enable monitoring and check newly produced logs. Old live rows do not become history.

Runtime API / Limited fallback means Docker API collection is being used because direct log-file access failed. Logs may arrive with limited capacity. Follow Health guidance for direct collection or forwarding; saved rows do not clear the warning.

See Logs for history versus live output.

Metrics are empty

1. Select an available Metric and broaden the time range.
2. Check the latest sample timestamp. Rates need multiple samples.
3. Check agent health and collection warnings.
4. For Kubernetes, check storage, workers, and kubelet trust.

Missing is not zero: an empty chart does not mean the workload is idle. Runtime metric collection is independent of log monitoring.

Check: the known workload has a recent saved log and runtime sample. A successful command or live row alone is insufficient.

If the problem remains

Record the release, environment/workload, time range, visible reason, and request/audit ID. Share redacted diagnostics with your support contact.

Exclude enrollment commands, keys, passwords, cookies, and private environment files. Keep data and identities; see Data and recovery.