SiftLog Platform – Enterprise Coming Soon

Find the Origin of the Failure – Before the Bridge Call Has Its First Status Update

SiftLog Platform – Enterprise is an always-on daemon that reads from your existing log
infrastructure, merges every source into a single time-ordered stream, and tells you which
service failed first. No agents. No instrumentation changes. No schema requirements. When
something breaks at 3am, you read 9

Find the Origin of the Failure – Before the Bridge Call Has Its First Status Update

SiftLog Platform is an always-on daemon that reads from your existing log infrastructure, merges every source into a single time-ordered stream, and tells you which service failed first. No agents. No instrumentation changes. No schema requirements. When something breaks at 3am, you read 9 lines instead of 61,000.

It connects to Loki, CloudWatch, Elasticsearch, Datadog, Google Cloud Logging, and local log files simultaneously. The correlation engine runs three detectors continuously against the merged stream. When a failure originates in one service and propagates downstream, SiftLog identifies the origin and names the propagation chain — before any engineer has finished their first log query.

What It Detects

• Cascade failures. 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.
• Anomaly rate spikes. 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.
• Service silence. 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.

What It Does Not Do

• Does not replace your log aggregation layer — it reads from it
• Does not store your logs — only the detected signals are written locally
• Does not require agents, sidecars, or any changes to your services or log format
• Does not perform distributed tracing — it correlates log events across services, not request spans
• Does not guarantee detection of every failure — correlation depends on logs being generated and accessible at the time of the event

SiftLog suppresses noise and surfaces signals. The output is a short list of events worth reading, not a dashboard with more numbers to interpret.

How It Works

SiftLog Platform is a single self-contained binary. Write a YAML config file pointing at your log sources. Run siftlogd start. The terminal UI launches automatically and begins processing immediately.

The correlator maintains a per-service sliding window of recent error events across all sources, merged into a single time-ordered stream. Clock skew between sources is detected and flagged inline. When signal conditions are met, the relevant events are extracted, the noise is suppressed, and the signal is written to the terminal and to persistent local storage.

Signal history is written to a SQLite database at ~/.siftlogd/signals.db. Post-incident review does not require log re-ingestion – the signal record is already there, timestamped and queryable.

Privacy and Air-Gapped Operation

• 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
• If the license server is unreachable, a 7-day grace period allows continued operation – the daemon does not stop mid-incident because of a network blip
• After activation, operation is fully offline-capable between verification windows

This matters for financial services, healthcare, defense contractors, and any organization with strict data residency requirements.

System Requirements

• Linux (amd64, arm64), macOS (Intel, Apple Silicon), or Windows 64-bit
• Network access to configured log sources
• Approximately 50MB disk space for the binary
• No runtime dependencies — single self-contained binary, no container requirements, no package manager
• A valid SiftLog Platform license key

Licensing

$4,999/year – up to 10 servers. One Team license covers up to 10 concurrent running instances across your infrastructure. The license is validated at startup and re-verified every 24 hours. A 7-day grace period applies if the license server is temporarily unreachable.

Enterprise agreements with unlimited deployments, air-gapped activation, SLA, and purchase order / net-terms procurement are available – contact us. M Media Software Lab is a registered US vendor with DUNS and EIN on file.

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.

SiftLog Platform |
Open Source Library on GitHub |
license@mmediasoftwarelab.com
lines instead of 61,000.

It connects to Loki, CloudWatch, Elasticsearch, Datadog, Google Cloud Logging, and local
log files simultaneously. The correlation engine runs three detectors continuously against
the merged stream. When a failure originates in one service and propagates downstream,
SiftLog identifies the origin and names the propagation chain — before any engineer has
finished their first log query.

What It Detects

• Cascade failures. 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.
• Anomaly rate spikes. 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.
• Service silence. 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.

What It Does Not Do

• Does not replace your log aggregation layer — it reads from it
• Does not store your logs — only the detected signals are written locally
• Does not require agents, sidecars, or any changes to your services or log format
• Does not perform distributed tracing — it correlates log events across services,
  not request spans
• Does not guarantee detection of every failure — correlation depends on logs being
  generated and accessible at the time of the event

SiftLog suppresses noise and surfaces signals. The output is a short list of events worth
reading, not a dashboard with more numbers to interpret.

How It Works

SiftLog Platform is a single self-contained binary. Write a YAML config file pointing at
your log sources. Run siftlogd start. The terminal UI launches automatically
and begins processing immediately.

The correlator maintains a per-service sliding window of recent error events across all
sources, merged into a single time-ordered stream. Clock skew between sources is detected
and flagged inline. When signal conditions are met, the relevant events are extracted, the
noise is suppressed, and the signal is written to the terminal and to persistent local
storage.

Signal history is written to a SQLite database at ~/.siftlogd/signals.db.
Post-incident review does not require log re-ingestion — the signal record is already
there, timestamped and queryable.

Privacy and Air-Gapped Operation

• 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
• If the license server is unreachable, a 7-day grace period allows continued
  operation — the daemon does not stop mid-incident because of a network blip
• After activation, operation is fully offline-capable between verification windows

This matters for financial services, healthcare, defense contractors, and any organization
with strict data residency requirements.

System Requirements

• Linux (amd64, arm64), macOS (Intel, Apple Silicon), or Windows 64-bit
• Network access to configured log sources
• Approximately 50MB disk space for the binary
• No runtime dependencies — single self-contained binary, no container requirements,
  no package manager
• A valid SiftLog Platform license key

Licensing

$990 — annual license, per server. One license covers one running instance
on one server. The license is validated at startup and re-verified every 24 hours. A 7-day
grace period applies if the license server is temporarily unreachable.

Volume pricing is available for multi-server deployments. Enterprise agreements with
air-gapped activation, SLA, and purchase order / net-terms procurement are available.
M Media Software Lab is a registered US vendor with DUNS and EIN on file.

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.

SiftLog Platform |
Open Source Library on GitHub |
license@mmediasoftwarelab.com