The Log Context You Need at 3 AM, Without the Log Bill
Fivenines does not ship your log stream anywhere. On Linux, the agent watches the systemd units you name, reports the error patterns behind them, and when an incident opens it reads the journal around that moment on your own server and sends back a redacted digest. You get the error patterns from when it broke, with a masked line for each. What we never get is the stream itself.
Built for teams monitoring production infrastructure
No credit card · 2-minute setup
Incident context
nginx.service
-
No Per-GB Anything
There is no ingestion charge, no retention tier and no add-on, because the architecture does not create the cost. We hold counts, error patterns and short masked excerpts - not your log volume - so there is nothing to meter. It is included on every plan.
-
An Incident Arrives With Evidence
When an incident opens, the agent reads the recent journal for your chosen units locally and uploads a bounded digest of what it found. The investigation starts with the errors from the minutes around the failure instead of a blank page and an SSH session.
-
It Knows What Is New
Error patterns are fingerprinted and dated, so the digest can say which templates had never appeared before this incident. "This error is new tonight" is the single most useful sentence in an outage, and it is the one a log search cannot hand you without work.
Deep dive
This Is Not a Log Platform, and That Is the Whole Point
Say it plainly, because the pricing claim depends on it: Fivenines does not store, index or search your logs. There is no log explorer, no query language, and no retention slider. If you need full-text search across a log estate, keep the tool you have for that - this is not a replacement for it.
What we take instead is a summary. Between incidents the agent sends per-unit error and warning counts plus one short masked sample line for each distinct error pattern it saw. When an incident opens it reads the recent journal locally and uploads a digest of that window: severity counts, and a capped set of error patterns each carrying one masked excerpt. The journal itself stays on your machine, and no raw copy is ever written on our side.
That is a deliberately smaller promise than the log products you are comparing this against, and it buys three things back: a bill that does not move when your application gets chatty, a privacy posture you can hand to a security reviewer, and a feature you can leave on without watching a usage meter.
What the Agent Actually Sends
Error and warning rates
Per unit, every collection tick, as counts for that window. This is the continuous half: a unit that starts logging errors is visible as a rising count rather than as silence until something else breaks.
Error patterns, fingerprinted
Log lines that differ only in their variable parts collapse into one pattern, so a thousand repetitions of the same failure arrive as one entry with a count instead of a thousand lines. Each pattern carries one masked sample.
First-seen timestamps
Every pattern is dated the first time it is observed and that date is never overwritten. It is what lets an investigation separate the errors that have been there all along from the ones that showed up with the incident.
The incident digest
Severity counts for the window plus the patterns behind them, each with one redacted excerpt of at most 500 characters. The window starts 5 minutes before the incident so the lead-up is included.
Nothing else
No log lines in bulk, no files, no journal export. The agent reads at most 2,000 recent lines on your machine and sends back only the digest built from them: the severity counts, plus one masked excerpt per distinct error pattern.
Only the units you listed
The allowlist is checked on the agent, again on our side before a capture is issued, and once more when the result is uploaded. Removing a unit stops new captures and refuses a late upload for it.
Deep dive
The Flight Recorder
Journald is queryable backwards, and that is the trick this feature turns. Fivenines does not need to have been streaming your logs to show you what happened at 03:14 - when an incident opens, the agent asks the local journal for the window around it, after the fact. You get retroactive evidence without a live pipeline, which is exactly the pairing that normally forces you into a per-GB contract.
The capture is automatic and bounded. It is triggered by the incident, covers each unit on your allowlist, and starts 5 minutes before the incident began. Captures are also rate limited on purpose: there is a per-host cooldown and a ceiling on how many can be in flight at once, because an incident storm is the normal case for a monitoring product and it arrives exactly when your servers are already busy. During a large one, not every host will produce a capture - the alerting itself is never affected.
Everything the agent uploads is redacted on your machine before it is sent. Masking is best effort rather than a guarantee, so treat an excerpt as a redacted log line and keep units that log sensitive payloads off the allowlist.
From Toggle to Evidence
Step 1
Turn it on for one host
Log monitoring is Linux and journald only, and ships disabled on every server. Enable it in the instance settings and list the systemd units the agent may read - up to 12 per host. Nothing in your journal is read until you do.
Step 2
Keep alerting as it is
Log monitoring does not open incidents. Your existing alerts - a host going offline, a metric threshold, a failing service, a down endpoint - are still what pages you. This feature has one job, and it is answering the question that comes next.
Step 3
Read the context when one opens
The capture is attached to the incident and returned by the MCP incident_context tool, alongside the incident timeline, the instance and its recent CPU and memory. An AI agent investigating on your behalf gets that in a single call, newest captures first.
Deep dive
Where You Read It Today
Being precise about this matters more than the sales copy, so: the captured context is read through the MCP server today, not in the web UI. The incident_context tool returns the incident with its timeline, the affected instance, that instance's recent CPU and memory, the log digests captured for the incident, and the error patterns first seen around the moment it opened - in a single call, from any MCP client. It was built for an AI agent doing the first pass of an investigation, and that is what it is good at.
The response is shaped for an LLM rather than exhaustive: it carries the 5 most recent captures and up to 20 newly seen error patterns. A host watching more than 5 units captures each of them, and the newest 5 are the ones the tool returns.
The feature is in beta and says so in the instance settings. An incident-page view of the same evidence is on the roadmap. If you want journal lines in the web interface right now, the separate systemd service monitoring module captures a short journal tail when a unit fails and shows it on the instance's Services tab.
One more boundary worth stating before you enable it: log signals do not carry alert thresholds and do not appear as chartable metrics. They are diagnosis context, deliberately, and the page you are reading would rather say so than let you find out during an incident.
The Privacy Posture, In Full
Off by default, everywhere
Every host ships with log monitoring disabled. It is a per-instance toggle, so enabling it on one server says nothing about the rest of the fleet.
An allowlist, not a firehose
The agent reads only the systemd units you name, up to 12 per host. There is no wildcard and no "everything else" bucket.
Masked before it is sent
Secret and PII masking runs on your server, before anything leaves it. It is best effort, so treat it as a safety net rather than a guarantee.
A digest, never the raw journal
Counts and short excerpts are the only content stored. There is no code path that writes a raw journal copy on our side.
Deleted after 30 days
Captured digests carry a retention stamp of 30 days and are purged by a nightly sweep once it passes, so the practical ceiling is that window plus up to a day.
Turning it off closes both doors
Disabling the module stops new captures immediately and makes the server refuse a late upload from a capture already in flight.
How It Compares
| Approach | Setup | Full-text search | Incident capture | Logs leave the box | Priced by volume |
|---|---|---|---|---|---|
| Hosted log platform | Shipper per host | Supported | Search the stream | All of them | Per GB ingested |
| Self-hosted stack (Loki, ELK) | Cluster to run | Supported | Build the query | To your storage | Storage you buy |
| SSH and journalctl | Built-in | On that one box | You, at 3 AM | No | Free |
| Fivenines | A toggle | Not supported | Automatic | Digest only | No |
Included on every plan
No ingestion charge, no retention tier and no add-on - there is no log volume to meter, because we do not take it.
Frequently Asked Questions
Is this log aggregation or log search? +
What does the agent actually read, and what leaves the server? +
Where do I read the captured context? +
How is this priced? +
What are the limits I should know about before enabling it? +
Explore next
Related Features
Server Alerts
The thresholds and triggers that open the incident log monitoring then explains.
Explore ->Workflows
Build the escalation path an incident follows, with rechecks and maintenance gates.
Explore ->Linux Server Monitoring
The CPU, memory, disk and network metrics the same agent already reports.
Explore ->Agent Security
Exactly what the agent reads, what it sends, and what it will never touch.
Explore ->See how Fivenines compares to other tools
Read our guide to the best infrastructure monitoring tools in 2026.
Get the log context an incident needs, without the log contract
14-day trial. No credit card required.
No credit card · 2-minute setup · Cancel anytime