Monitors

Monitor → Monitors watches your logs and hosts. It notifies you when something goes wrong, and again when it recovers.

A monitor has one alert condition and one way to recover:

             alert condition holds
   ┌────┐  ───────────────────────▶  ┌───────────┐
   │ OK │                             │ Triggered │
   └────┘  ◀───────────────────────  └───────────┘
             recovery (one of two options)

• Monitors are evaluated every 30 seconds.
• You get one notification when a monitor triggers and one when it recovers, not one every 30 seconds.
• Recent events on the Monitors page lists every state change.

Create a monitor

Click New monitor and work through the four steps.

1. Define the search

Choose what to watch.

Type	Watches
Logs	Log lines that match a service, host, status and/or text the message contains (case-insensitive). Leave a field empty to match anything.
Host metric	Average CPU %, memory %, disk % (fullest disk), swap % or 1-minute load, for one host or any host.
Host offline	A host (or any host) that stops sending data.

2. Set the alert condition

Type	Trigger when
Logs	The count of matching logs over the last N minutes is above, above or equal to, below, or below or equal to the threshold.
Host metric	The average over the last N minutes crosses the threshold on any host, or on the chosen host.
Host offline	The host sends no data for N minutes.

The window can be 1–1440 minutes. The default is 5.

Example: the count of error logs from service payments over 5 minutes is above or equal to 3.

3. Recovery

Choose one of two ways for the monitor to return to OK.

Option A: When the alert condition clears (default)

This works like a Datadog log monitor. The monitor recovers as soon as the alert condition no longer holds, for example when the count of errors in the window drops below the threshold again. A host offline monitor recovers when the host reports again.

Use it for volume-based problems: error spikes, high CPU, full disks.

Option B: When a recovery condition matches

The monitor stays triggered, even after the errors stop, until logs that match a different query arrive. That query can use a different pattern, a different service, a different status, or any combination.

Field	Meaning
Service, Host, Status, Message contains	What the recovery log looks like. Set at least one.
At least this many logs	How many matching logs are needed (default 1).

Only recovery logs that arrive after the monitor triggered count, so an old "recovered" line can't close a new incident.

Use it when the absence of errors doesn't prove the problem is fixed:

Alert condition	Recovery condition
payments errors ≥ 3 in 5 min	service payments, message contains gateway reconnected
"replication lag" warnings ≥ 1	service postgres, message contains replica caught up
"backup failed" from backup ≥ 1	service backup, message contains backup completed
checkout errors ≥ 10 in 5 min	service deploy, message contains rollback finished

After a recovery by condition, logs and metrics from before the recovery no longer count. The same burst of errors that triggered the monitor won't trigger it again; only new matching logs after the recovery can. In the monitor's status line, this shows as since recovered instead of in last 5m.

Option B isn't available for host offline monitors. They always recover when the host reports again.

4. Name and notify

Give the monitor a clear name, and optionally a webhook URL to notify.

Notifications

Logcore sends a POST with a JSON body to the webhook:

{
  "text": "[Logcore] 🔴 TRIGGERED: Payment gateway errors — error service:payments logs in last 5m: 3 (>= 3)",
  "alert_id": 12,
  "alert": "Payment gateway errors",
  "monitor": "Payment gateway errors",
  "state": "triggered",
  "message": "error service:payments logs in last 5m: 3 (>= 3)",
  "timestamp": "2026-11-11T10:42:00Z"
}

On recovery, state is ok and text starts with ✅ RESOLVED. With a recovery condition, the message says what recovered it, for example recovery condition met: 1 service:payments "gateway reconnected" logs since triggered (>= 1).

Slack

Create an Incoming Webhook for a channel and paste its URL (https://hooks.slack.com/services/…). Slack shows the text field.

Microsoft Teams

Create an Incoming Webhook, or a Workflows "post to a channel when a webhook request is received" flow, and paste its URL.

Anything else

Any HTTPS endpoint works: PagerDuty or Opsgenie webhook integrations, n8n, Zapier, or your own service. Use the state, monitor and message fields.

Managing monitors

Action	How
Pause	The power button turns a monitor off without deleting it or its history.
Edit	The pencil button. Saving resets the monitor to OK, and it's evaluated again within 30 seconds.
Delete	The trash button. Its events are deleted too.

Monitors created before this version keep working. If one has several conditions from the old editor, the editor shows them as a note and lets you remove the extra ones.

API

Monitors are available at /api/v1/monitors with a session cookie. The older /api/v1/alerts path still works.

{
  "name": "Payment gateway errors",
  "enabled": true,
  "conditions": [{ "type": "log_count", "service": "payments", "status": "error", "op": ">=", "threshold": 3, "window_minutes": 5 }],
  "recovery_mode": "condition",
  "recovery": { "service": "payments", "query": "gateway reconnected", "threshold": 1 },
  "webhook_url": "https://hooks.slack.com/services/…"
}

recovery_mode is threshold (option A) or condition (option B).

Tips

• Start with a few monitors that lead to real action: error spikes, full disks, offline hosts.
• Use a longer window for noisy signals such as CPU, so short spikes don't page you.
• For option B, make sure your application actually writes the recovery line. Test it once by searching for it in Logs.