Log alerting without shipping your logs
The Alert24 server agent searches your logs right where they live — on the server. Only match counts and a handful of sample lines leave the box. No log shipping, no central log store, no per-GB ingestion bill.
Built into the Server Agent you may already run for CPU, memory, and disk.
The search runs on your server. Only the results leave.
Agent reads new lines
Each interval the agent reads only the lines added since last time — incrementally, with log-rotation handling. It never re-alerts on historical logs.
Matching happens locally
Your glob paths and regex patterns are evaluated on the host. The raw log content stays on your infrastructure.
Only counts + samples sent
The agent sends match counts and up to 5 sample lines per search. Rules turn those into incidents with the evidence attached.
alert24-agent config — log_searches
"log_searches": [
{ "name": "app_errors", "source": "file",
"path": "/var/log/myapp/*.log", "pattern": "ERROR|FATAL" },
{ "name": "nginx_5xx", "source": "file",
"path": "/var/log/nginx/access.log", "pattern": "\" 5\\d\\d " },
{ "name": "ssh_failures", "source": "journald",
"unit": "sshd", "pattern": "Failed password" }
]Four ways to turn log lines into alerts
Every rule supports a sustained-duration threshold and a severity, and auto-resolves its incident when the condition clears.
Error spike
Fires when the number of matching lines in an interval crosses a threshold. The classic "too many errors" alert.
Example: App logs ERROR or FATAL more than 20 times in 5 minutes → high-severity incident with the matched lines attached.
metric: log_match_count
Error rate
Matches as a percentage of total lines. Catches a rising failure ratio even when overall traffic is low.
Example: More than 2% of nginx requests return 5xx for 5 minutes straight → page on-call. Pattern: " 5\d\d " against the access log.
metric: log_error_rate
Log volume / flood
Fires when lines per minute climb too high — a runaway logging loop that can fill the disk and take the host down with it.
Example: A retry storm writes 50,000 lines/minute to the app log → warn before the volume eats your disk.
metric: log_volume · above
Log silence (deadman)
Fires when lines per minute drops to roughly zero. If the app stopped logging, it usually stopped working — even though the host is still up and pingable.
Example: A request-processing service that normally logs every second goes quiet for 3 minutes → the process is wedged. Catch it before customers do.
metric: log_volume · below
An error-rate rule for the nginx 5xx search
{ "metric": "log_error_rate", "log_search": "nginx_5xx",
"operator": "gt", "threshold": 2,
"duration_seconds": 300, "severity": "high" }More than 2% 5xx for 5 minutes straight → a high-severity incident.
See what's in the log — not just “error count exceeded”
When a rule fires, the matched sample lines ride along into the incident. Your on-call engineer opens the page and immediately sees the actual log lines that tripped the alert — no SSH-ing into the box to find out what happened.
Incident: nginx_5xx error rate > 2% on web-03
10.0.0.4 - - [..] "GET /api/checkout HTTP/1.1" 502 0
10.0.0.7 - - [..] "POST /api/pay HTTP/1.1" 503 120
10.0.0.4 - - [..] "GET /api/cart HTTP/1.1" 500 88
... +3,114 matching lines (2.7% of requests)Your logs never leave your server
Traditional log platforms work by shipping every line off your servers into a central store, then billing you per gigabyte ingested. Alert24 inverts that: the search runs at the edge, on your host, and only the answer — a count and a few sample lines — comes back.
Log-shipping platforms
- • Every log line copied off the server
- • Billed per GB ingested and retained
- • A central log store you have to secure
- • Sensitive data leaves your boundary
Alert24 agent log search
- Matching runs on your host
- Only counts + up to 5 sample lines sent
- No central log store to breach
- No per-GB ingestion bill
Linux and Windows, files and system logs
One agent, three sources. Point it at files, the journal, or the Event Log.
Log files
Linux, macOS, Windows
Glob paths plus regex patterns across any plain-text log — application logs, nginx/Apache access and error logs, syslog files, and more.
"path": "/var/log/myapp/*.log", "pattern": "ERROR|FATAL"systemd journal
Linux
Search journald by unit and pattern — no need to configure file logging. Reads only new entries each interval.
"source": "journald", "unit": "sshd", "pattern": "Failed password"Windows Event Log
Windows
Watch the System, Application, and Security channels by event ID and level. Failed logins, service crashes, disk errors — all covered.
"source": "windows_event", "channel": "Security", "event_ids": [4625]Windows examples: failed logins (Security event 4625), system errors, and application crashes — by channel, event ID, and level.
How agent-side log search compares
| Capability | Alert24 agent | Log-shipping platforms |
|---|---|---|
| Search log files, journald & Windows Event Logs | ||
| Error spike, error rate, flood & silence rules | Varies | |
| Sample matched lines attached to the incident | ||
| Logs never leave your server | — | |
| No per-GB ingestion charges | — | |
| No central log store to secure | — | |
| Reuses the agent you already run for CPU/disk | — | |
| Auto-creates & auto-resolves incidents | Varies | |
| Links to on-call escalation & status pages | Varies |
Log-shipping platforms can do powerful full-text search and long retention. Agent log search is built for alerting — catching the problem without copying your logs off-box.
Included with the Server Agent on paid plans
Server agents are included on every plan — 3 on the free plan, and 5 per unit on paid plans at $18/unit. Log search monitoring requires a paid plan. Each agent also reports CPU, memory, disk, and service status, so log alerting rides on infrastructure you're already watching.
Alert on your logs. Keep your logs.
Add log search to the agent you already run. Error spikes, error rate, runaway floods, and silent-app deadman alerts — with the matched lines right in the incident.