Flashduty Monitors now supports Loki and VictoriaLogs

Teams using Grafana Loki or VictoriaLogs usually already have searchable logs. The harder part is turning those logs into alerts that wake the right person, include the log line that mattered, and recover cleanly.

Flashduty Monitors now supports Loki and VictoriaLogs data sources. You can keep the query language you already use and add Flashduty's alerting, recovery, notification, and on-call flow around it.

Why Flashduty Monitors?

Native Query Syntax, No New Learning Curve

Flashduty Monitors accepts native LogQL and VictoriaLogs queries.

Loki LogQL example:

count_over_time({job="mysql"} |= "error" [5m])

VictoriaLogs example:

_time:15m and level:ERROR | stats by (level) count(*) total | filter total:>10

There is no Flashduty-specific DSL to learn.

Three Alerting Modes for Different Scenarios

Flashduty Monitors provides three modes for log alerting:

Recommendation: for log alerts, start with Data exists mode. Put the filter in Loki or VictoriaLogs, and let Flashduty alert when matching rows return.

Flexible Alert Recovery

Flashduty Monitors provides three recovery strategies:

1. Automatic recovery: recover automatically when the value falls below the threshold.
2. Recovery threshold: define an independent recovery condition, such as $A < 5, to avoid oscillation near the trigger threshold.
3. Recovery query: configure a separate recovery query with ${label_name} variable substitution. This is useful for cases such as switch-interface status changes where trigger and recovery queries should be different.

# Alert query: search error logs
count_over_time({job="mysql"} |= "error" [5m])

# Recovery query: search recovery marker logs
count_over_time({job="mysql"} |= "recovered" [5m])

Include Raw Log Samples in Alerts

When a log alert fires, the first question is: which log line triggered it?

Flashduty Monitors supports associated queries, so alert messages can include raw log samples:

error log count: 23.000
Loki log time: 2026-01-09T10:23:45+08:00
Loki Log line: [ERROR] Connection refused to database server 10.0.1.5:3306

That gives the responder both the signal and the first piece of context in the same notification.

Configure an associated query, then render its result in the rule note template. See:

• Flashduty Loki alert rule configuration
• Flashduty VictoriaLogs alert rule configuration

Quickstart Examples

Scenario 1: Monitor Application Error Logs With Loki

Requirement: trigger Warning when error logs exceed 10 in 5 minutes, and Critical when they exceed 50.

count_over_time({job="myapp"} |= "error" [5m])

Thresholds:

• Warning: $A > 10
• Critical: $A > 50

Scenario 2: Detect HTTP 500 Errors With VictoriaLogs

Requirement: alert immediately when any HTTP 500 error appears.

_time:5m and status:500 | stats by (service) count(*) total | filter total:>0

Choose Data exists mode. Any returned data triggers an alert.

Scenario 3: Monitor Log Collection Health

Requirement: alert when a host has not reported logs for more than 15 minutes, which may mean the collector is down.

# Loki
rate({job="node-logs"} [1m])

# VictoriaLogs  
_time:15m | stats by (host) count(*) total

Choose Data missing mode. Continuous absence of data triggers an alert.

Where Flashduty fits

For Loki and VictoriaLogs, Flashduty keeps the log engine in place and adds the response layer around it: native LogQL and VictoriaLogs rules, edge deployment for private-network logs, recovery logic, raw log samples in notifications, grouping and suppression, Feishu, DingTalk, WeCom, Slack, PagerDuty, and 20+ notification channels, plus 7x24 on-call schedules.

Try it

Logs are useful only if the right signal reaches the responder.

Flashduty Monitors lets Loki and VictoriaLogs stay as the log engines, while Flashduty handles the alerting and response path.

Sign up for a free Flashduty trial and test it with one Loki or VictoriaLogs rule.

Flashduty Team | January 2026