Case study
A platform team tried to disprove this first.
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.
- 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
In their words
What they verified, and what they made us meet first.
Every claim below is quoted from their post and links back to it. The conditions they imposed are the ones the security page commits to.
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.
Questions
What people ask after reading this.
The same answers as the FAQ, because there is only one set.
Does Auditty delete or lose any of my logs?
No. Auditty writes every log line it processes to your own object storage, compressed and indexed, 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.
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 see my log data?
No. 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.
This holds for anomalies too. When a pattern is seen for the first time or its rate spikes, what reaches us is the template and the rates, which is enough to alert you and to identify the pattern. It is not a sample of your logs.
Reading the lines themselves is a request you make: a retrieval is served out of your own bucket, by a component running in your own account, returning only the rows you asked for. Everything forwarded to your own SIEM or log vendor goes there directly and never passes through Auditty either way.
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 in annual tiers against ingested volume. Your net position is that reduction minus the quote.