SiftLog Platform

Your logs are telling you what broke.
You just can't hear them yet.

SiftLog Platform ingests log streams from every source in your infrastructure, merges them in real time, and surfaces the origin of failures automatically. Cascade, anomaly, silence - detected and named, in under a second.

61,204
log events processed
9
lines worth reading
0.8s
to failure origin

The Problem

It is 3am.
Something is down.

You have engineers on a bridge call. Multiple dashboards open. Log streams from a dozen services scrolling in separate windows. The dashboard says latency is up and error rate is spiking.

It does not tell you which service failed first. It does not tell you whether this is a cascade from an upstream dependency. It does not tell you how long the affected services have been degraded.

Every engineer on that call is manually reading logs, comparing timestamps across systems with different clock configurations, trying to reconstruct a timeline inside their head. This takes 20 to 40 minutes in a well-run organization. It takes longer in a complex one.

SiftLog eliminates those 20 to 40 minutes.
CAS

Cascade Detection

When service A begins failing and service B starts degrading within a configurable time window - particularly when events share a trace ID - SiftLog identifies the origin service and names the propagation chain in order.

ANO

Anomaly Rate Detection

Per-service error rates are tracked against a rolling baseline. When a service exceeds the configured multiple of its recent error rate, it is flagged before your alerting thresholds fire.

SIL

Silence Detection

A service that stops logging is often the most important signal. SiftLog tracks per-service event volume and flags services that go quiet - a failure mode that manual log review consistently misses.

See It Work

20 microservices. One broken.
Found in 0.8 seconds.

An infrastructure issue causes a database connection pool in the auth service to exhaust. Within seconds, four services are generating thousands of error events. The other 16 are fine - and their normal INFO volume is drowning out the signal entirely. A senior engineer joins the bridge call and spends 15 minutes correlating timestamps manually. Nobody has the full picture yet. SiftLog, running continuously against all 20 sources, already does:

siftlogd - 20 sources active
[signal:cascade] auth-service -> api-gateway -> user-service -> session-manager 03:14:19.002 auth-service ERROR db connection pool exhausted (pool=50, waiting=312) 03:14:19.441 auth-service ERROR token validation timeout after 5000ms [trace: f8a21c] 03:14:19.887 api-gateway ERROR auth-service unavailable [trace: f8a21c] 03:14:20.103 api-gateway ERROR circuit breaker OPEN: auth-service 03:14:20.341 user-service ERROR upstream auth failure - cannot verify session [trace: f8a21c] 03:14:20.612 user-service ERROR retry 1/3 failed 03:14:21.008 session-manager ERROR session store unreachable - auth dependency down 03:14:21.204 session-manager WARN falling back to degraded mode [signal:silence] inventory-service - no events in 4m12s (baseline: 847 events/5min) noise suppressed: 61,204 events | signal: 9 events | elapsed: 0.8s

The cascade origin is auth-service. The propagation chain is named in order. The silence flag on inventory-service - a separate, unrelated issue - would have been invisible until someone noticed the service was gone. It is surfaced automatically. The 16 healthy services contributed zero noise.

Deployment

Three steps.
That is the entire deployment.

A single self-contained binary. No runtime dependencies. No container orchestration requirements. No changes to your existing infrastructure.

  • Copy the binary to a host Linux (amd64, arm64), macOS (Intel, Apple Silicon), or Windows 64-bit. No package manager. No container runtime.
  • Write a YAML config Point at your log sources - Loki, CloudWatch, Elasticsearch, Datadog, Google Cloud Logging, or local files.
  • Run siftlogd start The terminal UI launches automatically and begins processing immediately. No further configuration required.
siftlog.yaml
sources: - type: loki url: http://loki:3100 query: '{job="production"}' - type: cloudwatch region: us-east-1 log_group: /ecs/production correlator: flush_ms: 200 cascade_window_ms: 2000 anomaly_multiplier: 3.0 silence_threshold: 0.25

Log Sources

Built for infrastructure
that already exists.

No agents. No sidecars. No schema requirements. No changes to your services or your log format. SiftLog connects to the aggregation layer you already have.

Grafana Loki
AWS CloudWatch
Elasticsearch
Datadog
Google Cloud Logging
Local Log Files

File-based input supports glob patterns and tail mode. Additional sources planned.

Privacy & Air-Gapped Operation

Your logs never leave
your infrastructure.

This matters for financial services, healthcare, defense contractors, and any organization with strict data residency requirements. Enterprise agreements with fully air-gapped activation are available.

Talk to Us About Enterprise
  • No telemetry - the daemon does not collect, log, or transmit log content, signal results, or operational data
  • Your logs never leave your infrastructure - SiftLog reads from your existing aggregation layer; no log data is transmitted anywhere
  • The only outbound connection is license verification: key and machine ID, once at startup, then every 24 hours
  • 7-day grace period if the license server is unreachable - the daemon does not stop mid-incident because of a network blip
  • After activation, operation is fully offline-capable between verification windows
  • Enterprise agreements with air-gapped activation are available

Open Source Foundation

Evaluate the engine
before you license the platform.

SiftLog began as an open source Go library (MIT license). The correlation engine, all three signal detectors, and all adapter implementations are open source and can be reviewed in full before you buy anything.

The CLI is free. Run it against your logs today. No account, no signup, no credit card. Organizations evaluate the CLI first and license the Platform when they need it running continuously in production.

Explore the Open Source Library
terminal
$ go install github.com/mmediasoftwarelab/siftlog@latest $ siftlog app.log worker.log auth.log SiftLog v0.3.0 - 3 sources active [signal:cascade] auth-service -> api-gateway 03:14:19 auth-service ERROR db pool exhausted 03:14:19 api-gateway ERROR auth-service unavailable noise suppressed: 4,201 events | signal: 2 events

Why This Exists

Built at 2am. For 2am.

There is a gap between "the dashboard says something is wrong" and "I know what is wrong." Dashboards are good at the first thing. They are not built for the second thing. The second thing requires reading logs across services in time order, which every engineer has done manually at 2am at some point.

"I spent three years complaining about the gap between 'the dashboard says something is wrong' and 'I know what is wrong.' I built SiftLog at 2am on a Tuesday when I couldn't sleep and the problem was still interesting. If it helps you, it was worth the Tuesday."

- Jeff Mutschler, M Media Software Lab

Licensing

Per-server annual licensing.
Volume pricing available.

One license covers one running instance on one server. After purchase, your license key and binaries for all five supported platforms are delivered by email within one business day. SHA-256 checksums are included with every release.

M Media Software Lab is a registered US vendor (DUNS and EIN on file) and eligible for purchase order and net-terms procurement. Enterprise agreements with multi-site deployment, air-gapped activation, SLA, and vendor onboarding support are available.

Questions - license@mmediasoftwarelab.com

$999
per server / per year
  • Always-on daemon with terminal UI
  • Cascade, anomaly, and silence detection
  • All six log source adapters
  • Persistent signal history (SQLite)
  • Binaries for Linux (amd64/arm64), macOS, Windows
  • SHA-256 checksums with every release
  • Email support
  • 7-day grace period for license server downtime
Request a License

Tell us your deployment size and log sources. We respond within one business day. Volume and enterprise pricing available on request.