Free Online Log Analyzer with Issue Detection

For years the default way to investigate a log file was grep. You search for "ERROR", see what comes up, and work from there. This still works for small logs, but it falls apart once you are dealing with multi-megabyte files, deduplication, or patterns that span multiple lines.

A modern log analyzer does three things grep cannot easily do. First, it groups identical errors so 500 repetitions of the same line collapse to one row with a count. Second, it detects known patterns with context awareness, so boot-time noise is separated from real problems. Third, it pulls actionable recommendations for common errors, saving the 20 minutes you would otherwise spend Googling each one.

This tool processes up to 100 MB entirely in your browser. For files larger than that, split them first with `split -l 500000 large.log chunk_` and analyze each chunk.

CRITICAL, ERROR, WARNING, INFO, DEBUG, TRACE: these tags show up in most structured logs but people use them inconsistently. The analyzer counts each tag separately so you can tell at a glance whether a log is genuinely in trouble or just chatty.

CRITICAL means the service failed or is about to fail. Examples: out-of-memory, Policy Server disconnected, disk full, filesystem remounted read-only, Azure quota exceeded blocking new resources. These need immediate attention.

ERROR means a single operation failed but the service keeps running. Individual failed requests, one crashed worker that was restarted, temporary connection issues, a Cloudflare 5xx burst that recovered. Worth checking but not an emergency on their own.

WARNING means something unusual happened that might become a problem. Retries, slow responses, degraded modes, Git merge conflicts during CI, AWS throttling that the SDK is backing off from. Pattern-match these to spot trends before they escalate.

INFO, DEBUG, and TRACE are diagnostic. They are normally noise. Sudden spikes in INFO lines can indicate a verbose service accidentally left on. Sudden drops in INFO can indicate the service is hung.

Forcepoint appliances produce distinctive log signatures that admins see over and over. The CSRF token error is noisy on first boot but usually benign. The Alarms::signalAlarm messages indicate a worker process was reset, which is rarely fine in isolation but concerning if it repeats hourly. Policy Server and Filtering Service disconnects cause policy lookups to fail, which is user-visible.

The log analyzer recognizes all seven major Forcepoint patterns automatically. For a deeper troubleshooting reference, see the [Forcepoint Content Gateway troubleshooting guide](/blog/forcepoint-content-gateway-troubleshooting) on our blog.

Cloud logs have their own family of error patterns that look like normal HTTP responses but actually mean a quota or rate limit was hit. AWS calls these ThrottlingException or TooManyRequests, Azure uses QuotaExceeded or OperationNotAllowed, GCP uses "Quota exceeded for metric". The analyzer recognizes all three and points at the right console to request an increase.

AWS throttling is usually safe to ignore in small bursts because the AWS SDK retries with exponential backoff automatically. It becomes a problem when one runaway client (a stuck Lambda loop, a misconfigured CloudWatch poller) starts consuming the shared account quota and starves other workloads. The analyzer surfaces the count so you can see whether it is a steady drip or a sudden flood.

Azure and GCP quota errors are usually harder failures because they often block resource creation entirely. If you see these in CI/CD logs, the deploy did not actually go out. Check the relevant cloud console quota page first, then look at whether unused resources are still consuming capacity.

Cloudflare wraps your origin and serves a numbered error page when something goes wrong. The 5xx series is what you see in logs: 520 means an unknown origin error, 521 means origin is down, 522 means connection timeout, 523 means origin is unreachable, 524 means origin took too long (Cloudflare gives up at 100 seconds), 525 and 526 are SSL handshake failures.

These errors point at your origin server, not at Cloudflare. The most common cause for 524 is a slow database query or external API call that holds the connection open. For 521, check that the origin server is up and Cloudflare IP ranges are not blocked at the firewall.

Application logs are where most debugging happens. The analyzer detects EADDRINUSE (port already in use, often from a previous process that did not exit), UnhandledPromiseRejection (which terminates Node 15+ by default), Python ModuleNotFoundError (wrong virtualenv or missing pip install), and Java OutOfMemoryError (heap or metaspace exhaustion).

For each of these, the recommendations include the exact command to diagnose and fix. The EADDRINUSE recommendation, for example, includes the platform-specific command to find the process holding the port (`lsof -i` on Mac/Linux, `netstat -ano | findstr` on Windows).

HTTP 429 Too Many Requests is the API way of saying "slow down". The right response depends on the API. Some send a Retry-After header that tells you exactly how long to wait. Others (notably some older APIs) just block. The analyzer detects all 429 occurrences and recommends checking for that header before naive retry loops compound the problem.

CORS errors are confusing because they look like they happen on the server but are actually enforced by the browser. The server returned a response, the browser received it, then refused to give it to JavaScript because the Access-Control-Allow-Origin header was missing or wrong. The fix is always on the server side, not the client.

systemd unit failures are common on modern Linux. The analyzer recognizes the "entered failed state" log signature and recommends the right journalctl command to read the actual error.

A common failure mode of log analyzers is crying wolf. If every boot-time warning is flagged as critical, admins start ignoring the tool. This analyzer takes three steps to avoid that.

First, rules can include exclusion filters. The read-only filesystem detector, for example, excludes systemd-sysctl noise because those messages are normal on hardened appliances. Second, criticals that only fire during the first 200 lines of the log (boot phase) get auto-downgraded to warnings with a note explaining why. Third, patterns that represent normal behavior (systemd shutdown, tainted kernel warnings from loading vendor modules) are tagged EXPECTED so you can hide them with a single toggle.

The goal is that every CRITICAL you see is actually critical. This dramatically reduces alarm fatigue compared to regex-only tools.

If you have a network packet capture (.pcap file from tcpdump or Wireshark) instead of a text log, this tool will not parse it. PCAP is a binary format that needs a different decoder. Use the [PCAP Analyzer](/pcap-analyzer) which dissects Ethernet, IPv4, IPv6, ARP, TCP, UDP, and ICMP and detects SYN floods, port scans, ARP spoofing, RST storms, and DNS volume anomalies.

A useful pattern: if a service log shows "connection reset" or "broken pipe" errors and you cannot tell whether the client or the server caused it, capture 60 seconds of traffic with tcpdump, run the .pcap through the PCAP Analyzer, and check whether RSTs are coming from one side. The text log shows the symptom; the pcap shows which TCP endpoint pulled the trigger.