Log search
Finding the line that explains it.
Logs & Errors → Log Search queries the log store directly.
Searching
Filter by service, host, level, time range and free text. The result is lines, newest first, with context around each match.
| Filter | Use |
|---|---|
| Service | Narrow to one application |
| Host | Narrow to one machine — "is it only this box?" |
| Level | error and above during an incident |
| Time | Snap to the incident window |
| Text | The message, an id, a trace id |
Search by trace id when you have one. It gives you every line from every service for one request, which is usually the whole story.
Live tail
Follow a filter as lines arrive. Useful while you are making a change and want to see the effect immediately.
From an alert to the logs
Alerts, error groups and traces all link into log search with the filters and the time window already applied. That is deliberate — reconstructing a window by hand is where the transcription errors happen.
What is not here
Log analysis — volumes, patterns, and alerting on them — is Log analytics. This page is for finding a line; that one is for noticing that the number of lines changed.
Retention
Log retention is a property of the log store, not of AccelerUp. Check Data retention for what AccelerUp keeps about logs (metadata, patterns, counts) versus what the store keeps (the lines).
Where this behaviour lives: frontend/src/app/logs/, backend/internal/integration/elasticsearch.go. If the code and this page disagree, the code is right — please fix the page.
Part of Logs and errors — What the software said about itself, and what was unusual about it.