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.

Choose a database as a source, and its slow query and error log events join the list beside your servers’ lines: see Databases as a source.

Filters

Combine any of these to narrow a search:

Filter	Matches
Source	one or more servers, log sources or databases, picked from a single list grouped by kind: Servers, Custom Sources and Databases.
Tag	every server or log source carrying a tag — expanded to the matching sources for you, so you can search “all `web-tier` hosts” without listing them.
Level	one or more log levels (`error`, `warning`, `info`, …). A database’s slow statements have no level, so any level filter leaves them out (see Levels of database events).
Stream	what within a source produced the line: a file basename, a log file pattern’s name (`laravel-*.log`, see wildcards), `journald`, or a label the sender chose. Database events have no stream, so a stream filter leaves them out.
Database log	Slow queries, Error log, or both (Both logs, when neither is picked). Shown while a database is chosen as a source.
Time window	the last `1h`, `3h`, `12h`, `1d` or `5d`, then Custom: a length of your own, such as the last 2 weeks, or a range picked on the calendar, which shows its dates in place of the presets, with a ✕ back to the default. Logs are kept for 30 days: a window reaching further back is searched from 30 days ago, and one that ended earlier shows nothing.
Search text	free-text match within the message body of server and log-source lines. Database events carry keys and numbers, not text, so a search leaves them out.

Databases as a source

Choose All databases, or one or more databases, under Databases in Sources, and the list shows their slow and error logs: the same events as each database’s Logs tab, worded the same way. With no database chosen, the page shows server and log-source lines only. Choose servers and databases together, and their lines are merged by time, newest first.

The Databases group opens with All databases, then each database by name, with its engine and version (MySQL 8.4), or Counts only. All databases reads every database of your organisation each time the list loads. Choosing it replaces the databases chosen one by one, and choosing one of them replaces All databases.
It needs database.view as well as logs.view. Without it, Sources has no Databases group, and a saved view or a shared link opens without its databases. See Roles & permissions.
A server’s Logs tab shows that server’s lines only: it has no Databases group.
Each database’s privacy mode holds. A Clear names database shows its statement texts, schema and user names, and scrubbed messages; a Hashed one shows their keys only. A Counts only database sends no event, so it has no rows: choosing it shows <database> keeps counts only: its events stay on its host, so it has no rows here. Its counts are charted on its Logs tab. See Privacy modes.
A deleted database has no rows, and leaves the selection when the list next loads.
All databases covers up to 500. Past that, the list is refused with All databases covers more than 500 databases: choose up to 100 databases. Choose them by name instead, up to 100.
They are not log volume. Database events are included in the database’s price: they are never billed as log volume, and never count toward your ingestion limit.

Database log narrows the database events to Slow queries or Error log. It shows while a database is chosen, and is kept with your other filters and in a shared link.

Levels of database events

An error-log record takes a level from its severity. A slow statement has none: it shows slow, in a colour of its own.

Database event	Level	Level filter
An error-log record or count line of severity Error, a crash included	`error`	Error
… of severity Warning	`warning`	Warning
… of severity Note	`info`	Info
… of severity System	`notice`	Notice
A slow statement, or a storm’s or the daily budget’s summary	slow	none: any level filter leaves it out

A level filter of only Emergency, Alert, Critical or Debug shows no database event. The row keeps MySQL’s own word for the severity beside the level.

What a search or a stream filter leaves out

The log store holds keys, numbers and codes for a database event, never a text, and the event has no stream. So a search or a stream filter leaves database events out, and a note above the list says so:

Search covers server and custom-source lines: database events carry keys and numbers, not text. Clear the search to list them.
Stream filters cover server and custom-source lines: database events have no stream. Clear the stream filter to list them.

With servers or log sources chosen too, their lines are listed alone. With databases alone, the list is empty until you clear the search or the stream filter.

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.
database_before pages database events further back, beside before, while a database is chosen. after is refused with a database source.
The page size is configurable up to 500 lines (200 by default).

Paging back never shows a line twice, and never skips a line from a server’s agent, which stamps every line with its own nanosecond time. Lines sent to a log source keep whole seconds, so several can share one timestamp; when such a group falls on a page boundary, the rest of the group can be skipped. Database events are never shown twice or skipped, even when several share one time.

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. With a database chosen, Group by Level adds slow and the database events’ levels, and Source a group for each database, counted in events: a summary or count line counts as the events it stands for, and the count reads N events. Database events have no stream, so grouping by Stream with databases alone shows No groups in this window. Clicking a group narrows the list to its lines: slow sets Database log to Slow queries and keeps only the chosen databases, a level sets the level filter, and a database’s group chooses that database alone.

Database rows

Each database event is one row: its time (a slow statement’s start, as MySQL records it, or the time written on an error line), the database’s name, its level or slow, the log’s name, Slow query log or Error log, where a line’s stream would be (muted: it is not a stream a filter matches), and the event:

Event	Shows
A slow statement	Its query time and rows examined, then the statement: its normalised text in Clear names mode, otherwise its key, with Queries statement or No Queries statement; the schema’s name, or its key
A summary	N events summarised, Storm or Daily budget, and the statement
An error-log record	Its severity (Error, Warning, Note, System), its code linking to MySQL’s reference (crash for a crash), its subsystem, the scrubbed message in Clear names mode or its key, and +N continuation lines, not sent
A count line	Its severity and, for example, 37 more lines counted, not listed: more than 300 error-log lines in that minute.

Show full log contents shows the whole statement text or message, wrapping, and adds a slow statement’s lock time, rows sent and account, a summary’s total and longest time and rows examined, and Text needs clear names beside a key, as the database’s Logs tab shows them.

Clicking a row opens the database’s Logs tab on that log, with the page’s time window. A link inside the row does its own thing instead: Queries statement opens the statement on the database’s Queries tab, a code opens MySQL’s error reference, and a schema’s key, or a statement’s MySQL key, opens Reveal on the host, with the command to run on a collector of that row’s database (see Revealing a key on your host).

Database events can arrive late. An event reaches the log store up to a minute after its time, and an RDS or Aurora error line up to about 6 minutes after. A list you have already scrolled past that time shows it on the next load.
When the database events cannot be read in time, the page shows The log store did not answer in time. Try again in a moment.

Layout

Two icons on the title row change how the page is laid out. One puts the filters in a column on the left, with the results taking the rest of the width. It is available when the window is wide enough, and otherwise says so. The other hides the volume chart, which also stops it being fetched. The list of lines then fills the window down to the bottom. Your choices are saved to your account, so they follow you to another browser. The Logs page and a server’s Logs tab remember theirs separately.

Live views

The Logs page has a Live tail button that checks for new lines every 6 seconds, and a server’s Logs tab refreshes itself every 15 seconds. A thin bar along the top of the list shows when the next check lands.

Both pause while you scroll down the list, so the lines you are reading never move. Scrolling back to the top, or clicking Live tail paused, catches up at once. They also pause while the browser tab is hidden.
Both keep the newest 2,000 lines. Older lines drop off the bottom as new ones arrive. Scroll to the bottom to load them again. A very long line shows its first 8,192 characters in the list; open the line to see all of it.
The Live tail turns off when you group the results or pick a custom time window, and a server’s tab stops refreshing on a custom time window. Neither can gain new lines. Turning the Live tail back on clears the custom window and returns to the last relative one you had, such as the last day.
The Live tail is off while a database is chosen. The button is disabled, and its hover says why: Database events arrive once a minute, dated by the database’s own clock, so a live tail would miss them: refresh instead. Choosing a database while it runs turns it off.
On a server’s Logs tab, the time window is the page’s own: the one its charts, Incidents and other tabs use. Choosing one here, or zooming on the histogram, changes it for every tab. Clicking a gap row is the exception: it shows that span on the Logs tab only, and the ✕ on its dates returns the tab to the page’s window.
When lines arrive faster than a live view can show them, it marks the gap with a row reading “Lines between … and … were not loaded”. Click it to load that span. If gaps keep appearing, a note under the controls suggests narrowing the filters.
A line can reach the log store late when its source is slow or backlogged, and so do imported lines: a new file’s last 72 hours, and lines written while the agent was stopped (see tailing behaviour). A live view only asks for lines newer than the newest it has, so such a line can be missing until you reload the page or pick a time window that covers it.
On a server’s Logs tab, a note names the lines delivered late after the server could not reach WatchTower15: 412 lines from 06/10/2026, 09:12 – 11:25 UTC were delivered late. A live view does not pick up late lines. Show them opens that window on the Logs tab only, as a gap row does. While the agent is still sending lines from that time, it reads Lines from 06/10/2026, 09:12 – 11:25 UTC are still arriving from the host (412 so far). There is one note for each such gap that ended in the last 24 hours and holds at least one line, up to three, newest first, and ✕ hides one in this tab.

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.

With a database chosen, its events are in the bars too, counted in events: the error-log records in their levels’ bands, and the slow statements in a band of their own, slow queries, after the levels. A storm’s or the daily budget’s summary counts as the events it stands for. Database events counted in events, above the chart, says on hover what is counted: the events stored in the log store. A database’s own Logs tab charts its reader’s counts, which also count events that were never stored (a record dropped rather than risk sending a value, for example), so the two charts can differ.

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.

With a database chosen, the level counts include its events, in events, beside a count of slow and error events; the stream facet counts server and log-source lines only.

Context

Found the line that matters? Context pulls the lines immediately before and after it (by time, on the same source and 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 database event has no context of its own: clicking it opens the database’s Logs tab on its log, with the page’s time window (see Database rows).

A typical investigation

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

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”.
Slow and error logs — a database’s slow statements and error log, readable here as a source.