AI data engine for Kubernetes logs
Forward the 5% that matters.
Keep 100% of the data.
Auditty classifies every log line on the node, before it leaves your cluster — from the first line, with nothing to configure. Noise is summarised rather than deleted: the full raw stream lands as Parquet in your own bucket, and any suppressed pattern comes back on demand.
Kubernetes DaemonSet · your cloud account · nothing to configure to start
Running in production at
AppsFlyer cut log volume 50% across 1,000+ production servers. Read how they proved it →
The trade-off nobody wants
Cutting log costs usually means deleting data and hoping.
Sampling throws away the one line that explained the outage. Drop filters are written months before the incident that needed them. Cheaper storage tiers only move the invoice.
What they share is that they make you decide, permanently and in advance, which data will matter later — and you find out you guessed wrong during the incident, when it is far too late to change your mind.
Auditty removes the decision. Reduce what you forward as aggressively as you like, because the raw data is still sitting in your own bucket, indexed, and one click away.
It decides on its own
Every line is classified on the node in microseconds — plain text, JSON or logfmt, with nothing to declare and nothing to tune. Repetition collapses into a summary. First occurrences, rate spikes and statistical outliers are forwarded, so an anomalous instance still gets through even when its pattern is being suppressed.
Keep everything
Suppressed does not mean deleted. The complete raw stream is written as compressed Parquet to your own S3, GCS or Azure bucket — an open format you can read with your own tools, with or without us. Any suppressed pattern can be pulled back later by pattern, time range, or the value of a specific field.
Check it yourself
Every summary carries a link back to the exact lines it replaced, and the identifiers from those lines are indexed inside the summary itself — so you can confirm a specific request survived without retrieving anything. The claim that nothing was lost is one you can test on any summary on the page, not a number we report to you.
The difference
Same pods. Same vendor. A fraction of the bill.
Flip it. The left-hand volume never changes — that is what your workloads emit. What changes is how much of it you pay to ship, and where the rest goes.
Independently verified
AppsFlyer replayed a peak hour of production through it before trusting it.
They refused a black box, ran the evaluation in their own segregated account, and wrote up what they found — including the conditions we had to meet first.
AppsFlyer Engineering November 2025“We didn’t see any regression in our ability to investigate incidents, and we can easily opt out any sensitive components.”
AppsFlyer’s platform team refused to take log suppression on trust. They mapped roughly 1,800 log sources, found that only a single-digit percentage of their logs were actually used for debugging or incident response, then built an offline framework that replayed a full peak hour of production traffic through Auditty in a segregated account — before a single production workload was touched.
Read the full write-up- 66%
- average suppression across their top log emitters, in evaluation
- 50%
- sustained reduction across their Kafka infrastructure, in production
- 1,000+
- servers running the agent, across ~50 Kafka clusters
What they verified independently
Nothing leaves your perimeter
“All processing occurs locally in our clusters or controlled accounts, ensuring that no data leaves our premises.”
It fails open
“If the agent fails, it fails open, ensuring logs flow normally.”
Identifiers survive suppression
“The agent distinguishes log segments of business significance like UUIDs and does not suppress them.”
Service owners stay in control
“The Configuration as Code approach enabled service owners to trust the system, providing them with the flexibility to opt in or create exception rules…”
Quoted from AppsFlyer Engineering. These are claims made elsewhere on this site, each restated in the words of a team that set out to disprove them first.
How it works
Three steps, and none of them are in your data path.
Deploy one DaemonSet, and name what it may touch
The agent runs on each node and filters container logs in place. Your container runtime is untouched and unaware of it, your log shipper keeps watching the same path and finds the filtered stream there, and nothing new sits in the network path — so there is no fresh failure mode between your workloads and your logging. Reading is a whitelist: you name the namespaces and workloads it may touch, and it silently ignores every pod you did not name.
helm repo add auditty https://charts.auditty.ai
helm install auditty auditty/edge \
--namespace auditty --create-namespaceIt starts deciding immediately
There is nothing to train and no rules to write. Patterns are recognised from the first line, and the defaults are the conservative ones: a pattern has to prove itself genuinely repetitive before it is summarised, errors and warnings are never suppressed at all, and something merely widespread — emitted once by each of two hundred pods — is read as telemetry rather than as noise.
new pattern, never seen before → forward
rate spike above baseline → forward
error · warn · fatal · panic → forward, always
outlier inside a summarised set → forward on its own
repetitive info · debug → summarise + archiveGet it back when you need it
Every summary carries a link back to the raw lines behind it. Follow it and Auditty returns the actual log lines out of your own bucket, including the ones from a few seconds ago that have not landed there yet. Narrow to a single field without re-running anything.
fingerprint 9f2a71c4e8b3
window 14:20:00 → 14:25:00 UTC
where latencies.kong > 2500
15,293 lines scanned · 41 matched · 1.2sSafe to run
You are about to let something touch your log files. Here is exactly what it will and will not do.
The scariest part of this product is the part we would rather you interrogate now than during a security review.
Never drops a line
Under load Auditty slows down rather than discarding. There is no drop path to fall back on, so it cannot silently shed data.
Bounded by design
1 vCPU and 256 MiB per node, enforced — not a recommendation that degrades under a traffic spike.
Gives your logs back instantly
Restoring your log pipeline is the first thing it does on the way out, ahead of its own cleanup, so logging is working again within milliseconds. After an abrupt kill, the same happens by itself on restart.
Never touches what it does not manage
Recovery is scoped to pods that match an interception rule. Logs Auditty was not asked to handle are left strictly alone.
Holds no cloud credentials
Your bucket is read by your own agent inside your account. The Auditty control plane has no path to your object storage at all.
One egress path
Nodes talk to a single in-cluster service, which is the only component that talks outbound. Nothing else needs a route to the internet.
Questions
The things people ask before they trust this.
Short answers here; the full set is on the FAQ page.
What is Auditty?
Auditty is an AI data engine for Kubernetes logs. It classifies every container log line on the node, before it leaves the cluster, forwards the small fraction of lines that carry information to your existing SIEM or log vendor, summarises repetitive lines instead of shipping them, and writes 100% of the raw stream as compressed Parquet to your own cloud storage.
The result is that you pay to ingest a fraction of your log volume while keeping every original line queryable. Auditty runs as a DaemonSet and is designed to sit alongside your current tooling rather than replace it.
How is Auditty different from log sampling or drop filters?
Sampling and drop filters destroy data permanently, so they force you to decide in advance which logs will matter during an incident that has not happened yet. Auditty never destroys anything: a suppressed line is still written in full to your own object storage, and can be retrieved later by pattern, time range or field value.
That difference changes how aggressively you can reduce. With sampling, cutting 95% of volume means accepting a 95% chance that any specific line is gone. With Auditty, cutting 95% of forwarded volume costs you nothing but a lookup if you later need one of those lines.
Does Auditty delete or lose any of my logs?
No. Auditty writes every log line it processes to your own object storage as compressed Parquet, including the lines it suppresses from the forwarding path. Suppression only determines what you pay to ship to your log vendor; it never determines what exists.
Under load Auditty applies back-pressure and slows down rather than silently shedding data; there is no drop path to fall back on. We also monitor continuously for any discrepancy between what was ingested and what was accounted for, and a real one pages us rather than waiting to be noticed by you. What you can check yourself is any individual summary, which carries a link back to the exact lines it replaced.
Does Auditty see my log data?
Only for anomalous patterns, and never in the steady state. Ordinarily what leaves your cluster is log templates — the shape of a line with all values masked to placeholders — plus counts, rates, timing and node, namespace and workload names; a template records that a line of a given shape occurred, not what was in it, and cannot reconstruct the original. When a pattern trips anomaly detection, Auditty also sends a sample of the line that triggered it and some of its extracted values.
That exception is what allows an alert to tell you which request broke rather than only that something did. It is scoped to the pattern that tripped detection and never applies to the repetitive bulk of your logs.
If you would rather nothing but templates ever left your cluster, anomaly signals are a licensed capability and we will issue a licence without them, in which case the capability is not active in your deployment at all. Everything forwarded to your own SIEM or log vendor goes there directly and never passes through Auditty either way.
Does Auditty replace Datadog, Splunk or my existing SIEM?
No. Auditty sits upstream of your existing log vendor and reduces what reaches it. You keep your dashboards, alerts, queries and runbooks; they simply operate on a stream that no longer contains the repetitive lines nobody reads.
This is deliberate: replacing an observability stack is a multi-quarter migration, while reducing what you send it is a Helm install. Auditty forwards to file destinations, object storage and existing SIEM or log vendors, with no per-connector licensing.
How much can Auditty actually save me?
Savings depend on how repetitive your logs are, and most production log volume is highly repetitive. Deployments typically settle at forwarding between 3% and 10% of ingested volume, with the remainder summarised and archived.
As an illustration, at 500 GB per day and a $0.50 per GB ingest rate, forwarding 5% reduces annual ingest cost from roughly $91,000 to roughly $4,600, with about $6,300 per year of object storage to retain a full year of the raw data in compressed form. The calculator on the pricing page lets you substitute your own volume and rates.
Those figures are the change to your ingest and storage bill. They do not include Auditty’s own licence, which is quoted per node against your fleet — your net position is that reduction minus the quote.
Data that matters.
Stop paying to ship noise you will never read.
Bring a week of your own logs. We will show you what Auditty would have forwarded, what it would have summarised, and what it would have cost.