Search & explore logs

Log search in WatchTower15 is built for incident work: narrow fast with structured filters, see the shape of the volume with a histogram, break it down by facets, and expand context around any interesting line — all scoped to your organisation and gated by the logs.view permission.

Every query runs through the WatchTower15 API, which always constrains results to your organisation before they reach the log store. You never query the store directly.

Filters

Combine any of these to narrow a search:

Filter	Matches
Server	one or more servers by identity — internally resolved to their log streams.
Tag	every server carrying a tag — expanded to the matching servers for you, so you can search “all web-tier hosts” without listing them.
Level	one or more log levels (error, warning, info, …).
Source	the log_source label (a file basename, or journald).
Time window	an absolute or relative from/to range.
Search text	free-text match within the message body.

Free-text is matched literally and safely

Text you type in the search box is matched as a literal substring — regular-expression metacharacters are escaped for you, so searching for GET /v1/users?id=5 does exactly what it looks like rather than being interpreted as a pattern.

The results list

Results are returned newest-first and paginated with cursors, not offsets, so paging stays correct even as new lines arrive:

• before pages further back in time (older lines).
• after pages toward now, and is how a live tail advances.
• The page size is configurable up to 500 lines (200 by default).

Because paging is cursor-based on nanosecond-precision timestamps, you never get duplicated or skipped lines at page boundaries during a burst.

You can also request a grouped view — counts per log_source, log_level, or server — to see the make-up of a result set at a glance.

Histogram

The histogram plots log volume over your selected window, automatically choosing a bucket size that gives a readable number of bars for the range, and breaking each bar down by level. It’s the fastest way to answer “when did the errors start?” — spot the spike, then click into that window.

Facets

Facets answer “what are the top values?” for a field across the current query — for example the busiest log_sources, the servers producing the most error lines, or the most common levels. Each facet returns the top values ranked by count, so you can pivot an investigation without writing a new query.

Context

Found the line that matters? Context pulls the lines immediately before and after it (by time, on the same stream), reconstructing the surrounding sequence of events the way you’d read them in the original file — without losing your place in the filtered search.

A typical investigation

1. Filter by the affected tag (e.g. service:checkout) and level error over the last hour.
2. Read the histogram to find the minute the errors began.
3. Narrow the time window to that spike.
4. Use facets to see which log_source or server dominates it.
5. Open context on a representative line to read the lead-up and aftermath.

Related

• Logs overview & shipping — how lines get here and how log_source/levels are set.
• Retention, throttling & limits — how far back you can search.
• Tagging — the tags that power “search every host tagged X”.