Logstag
TR Request a trial
Alerts

Alerts that explain themselves.

More than 200 checks ship with Logstag. Each alert says what is wrong, why it matters, what usually causes it and what to do.

Request a trial
Alerts overview

What is open, and how fast it closes.

One page for every alert on every database: what is firing now, how long alerts take to resolve, and how each day compares with your SLA.

The Alerts page in the Logstag app: active and critical alert counts, average time to resolution and alerts fired over the past week, above a chart of alerts raised and resolved each day, with the part that breached an SLA in red.

  • What is open now

    Active alerts across every database, with the critical ones counted apart.

  • How fast they close

    Average time to resolution over the selected week.

  • Against your SLA

    Alerts raised and resolved each day, with any part that breached your SLA marked in red.

Built-in checks

More than 200 checks, no rules to write.

Thresholds come with each check. You don't build alert rules or tune numbers before Logstag is useful: connect a database and the checks for its engine start running.

Blocking queriesIdle transactionsReplication lagLog file near capacityxp_cmdshell enabledCollection scansTablespace usageMemory fragmentationVersion approaching end of lifeAgent stopped sending

Engines with built-in checks

  • PostgreSQL
  • SQL Server
  • Oracle
  • MongoDB
  • Redis
  • Valkey
  • ClickHouse

Further reading: Database reliability is not uptime.

Inside one alert

The runbook comes with the alert.

The text below is from the real PostgreSQL blocking-queries check, shortened. Every check carries the same sections, and the alert adds the context it fired with.

HighBlocking Queries DetectedPostgreSQL · Activity

Impact

Blocking queries create a queue of dependent operations that cannot proceed, leading to application timeouts, connection pool exhaustion and degraded user experience.

Common causes

  • Long-running transactions holding locks for extended periods
  • Table-level locks from schema changes (ALTER TABLE, CREATE INDEX)
  • Missing indexes causing queries to take more locks than necessary

Recommended actions

  1. Identify the blocking queries and the sessions they are blocking.
  2. Check how long the blocking transactions have been open.
  3. Set statement_timeout to prevent indefinite blocking.

Context (example)

blocking_pid 4127 · blocked 3 · wait 2 m 14 s

Keeping the list short

Many databases with one problem are one line.

Repeats merge

The same condition on the same object is one alert, not a new one every poll.

Groups by check

The list groups alerts by check, so a problem across your fleet reads as one row with a count.

Mute with a scope

Silence a check for an instance, a database or one object. The rule also covers future alerts of the same shape, until you remove it.

Resolve on their own

Once its condition clears, the alert resolves itself. Nobody has to close it by hand.

SLAs

Admins set time limits by check, severity, instance or database. Alerts show whether they are on track or have breached.

Silence is an alert

If a monitored server stops sending data for a day, you get an alert instead of an empty chart that looks healthy.

Zero configuration. Connect and go.

No rules to write and no numbers to tune. Once a database is connected, every check for its engine starts working on its own.

Request a trial