Database Explorer
The Database Explorer is the inventory of every monitored database: which databases Logstag watches, whether they and their hosting instances are reporting, and which ones need attention because of host pressure or active alerts.
What the page shows
- One row per monitored database, paired with the instance that hosts it.
- Online means both the database and its instance are active; if either is inactive, the row shows Offline.
- CPU and memory are instance-level measurements — when several databases share a host, they show the same values. They describe host pressure, not one database's consumption.
- Alert chips summarize the database's active alerts by severity.
Selecting a row opens the database's detail view: overview metrics and trends, the health score, the schema inventory, and the database's alerts.
Reading it
Scan Status first, then the alert chips, then CPU and memory. A healthy fleet reads as a column of green Online badges and grey zero chips — anything colored is your triage list, and the row's detail page says why.
Database List
One row per monitored database with its hosting instance. Click a row to open the database's detail view.
Columns
- Database — the database's name with its engine icon.
- Instance — the hosting instance. Filterable by instance.
- Engine — PostgreSQL, SQL Server, MongoDB, Redis, Valkey, or Oracle.
- Status — Online when both the database and its instance are active; Offline otherwise.
- CPU — the host's average CPU usage. Instance-level: databases sharing a host share this value. Rising is shown red.
- Memory — the host's average memory usage, same instance-level scope and coloring.
- Alerts — active alert counts as severity chips: Critical, High, Medium, Low. Zeroes render muted.
The list can be searched by database or instance name, filtered per column (engine, status, CPU and memory ranges, with or without alerts), sorted by most columns, and paginated.
Reading it
Sort by Alerts to triage, or filter to a single engine when rolling out an engine-specific change. Because CPU and Memory are host-scoped, several red rows on the same instance are one host problem, not several database problems — fix it once at the instance.
Database Detail
Selecting a database opens its detail view. The header shows the database name, online or offline status, engine and version, hosting instance, and last-updated time.
The detail page has these tabs:
| Tab | Purpose |
|---|---|
| Overview | Summary metrics, the health score, database information and server resources, and trend charts. |
| Schema | Object counts, the object-size treemap, and the searchable object inventory. |
| Alerts | Active alerts for the selected database and its hosting instance. |
Redis and Valkey do not show the Schema tab — they are key-value stores without a schema model.
Metric definitions and how each value is calculated live in the Overview reference and the Schema reference.
Alerts
Database Explorer combines database-scoped and instance-scoped alerts for quick triage: severity chips on the list page, and a full alerts view on the detail page with severity, status, type, assignment, and SLA context. The health score's dimension rows link straight into this tab, pre-filtered to the alerts behind a dimension.
Data Freshness
Database Explorer uses collected metrics and metadata. Values reflect the selected time window and the most recent data available to Logstag.
Runtime and workload signals can update quickly when high-frequency collectors are enabled. Schema and heavier metadata can take longer because they are collected less frequently. If a metric is unavailable, it usually means the relevant collector has not reported data for the selected time window, the engine does not expose that signal, or the monitoring user does not have the required visibility.
Data Boundaries
Database Explorer is an observability surface. It shows operational metadata, metric summaries, schema metadata, alert context, and health indicators. It does not copy application table rows, MongoDB documents, or Redis key values into the product view.
Some displayed metadata can still be sensitive, including object names, usernames, client addresses, configuration values, and alert context. Access to Database Explorer should be limited to users who are allowed to inspect database operational metadata.