# Auditty: complete reference > Auditty forwards the 5% of your logs that matter and keeps 100% of the raw data in your own cloud storage, then proves nothing was lost. This file contains the full text of every answer published on auditty.ai. Source: https://auditty.ai. Contact: hi@auditty.ai. --- ## What Auditty is Auditty is an AI data engine for Kubernetes logs. It runs as a DaemonSet and classifies every container log line on the node, before the line leaves the cluster. Lines that carry information are forwarded to the customer's existing SIEM or log vendor. Repetitive lines are replaced by summary events rather than being shipped. Independently of both decisions, 100% of the raw stream is written, compressed and indexed, to the customer's own cloud storage bucket, where any suppressed line remains retrievable by pattern, time range or field value. Auditty does not replace an existing observability stack. It sits upstream of it and reduces what reaches it, so dashboards, alerts and queries continue to work against a stream that no longer contains the repetitive lines nobody reads. ## Verified properties | Property | Value | | --- | --- | | Agent CPU ceiling | 1.5 vCPU per node, enforced rather than advisory | | Agent memory ceiling | 768 MiB per node, enforced rather than advisory | | Agent memory in steady state | 60 to 80 MB per node | | Container privileges | Not privileged; two scoped Linux capabilities (DAC_READ_SEARCH, SYS_PTRACE) | | Classification speed | Microseconds per line | | Added application latency | None; processing happens after the line is written and cannot block the writer | | Log restoration after a crash or restart | Automatic, within milliseconds, with nothing to repair by hand | | Fleet rule propagation | ~1s | | Data loss under load | None; Auditty applies back-pressure rather than dropping | | Raw logs sent to Auditty | None, anomalies included; only masked templates, counts and metadata | | Customer cloud credentials held by Auditty | None | | Log formats | Plain text, JSON (including nested and dotted keys), logfmt | | Deployment targets | Kubernetes DaemonSet, systemd service, batch CLI | | Archive location | The customer's own S3, GCS or Azure bucket, compressed and indexed in an open format the customer's own tools can read | | Licensing | On ingested volume, quoted in annual tiers. Node count is not a billing lever | ## Independent verification Everything above is Auditty's own description. This section is not: it summarises an evaluation published by a customer's platform team, on their own engineering blog, under a named author. **How We Cut Log Volume Without Blindfolding Production** by Daniel Rogatchevsky. AppsFlyer Engineering, November 2025. https://medium.com/appsflyerengineering/how-we-cut-log-volume-without-blindfolding-production-05d82be13ec9 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. Reported results, each with the scope it measured. These are not interchangeable, and the difference between the evaluation figure and the production figure is stated deliberately: - **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. Properties they verified themselves, quoted from the post: - 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…" On whether suppression cost them incident response: "We didn’t see any regression in our ability to investigate incidents, and we can easily opt out any sensitive components." Auditty is also in production at ZoomInfo. ## How a log line is processed 1. **Interception.** Auditty intercepts each container's standard output on the node. The container runtime is unaffected and requires no reconfiguration, and existing log shippers keep reading the node's logs and find the reduced stream there. Nothing is inserted into the network path between the workload and its logging, and no sidecar is injected. 2. **Classification.** Each line is reduced to its pattern, with the values that vary between lines masked out, so many variations of one log statement collapse to one identity. Plain text, JSON and logfmt are all handled without a schema, a parser or a customer-supplied regex, in microseconds per line. 3. **Extraction.** The particulars are kept as the pattern is recognised: levels, status codes, durations, trace and request identifiers, and other identity-shaped values such as UUIDs, internal addresses, prefixed keys and long tokens, so the specifics survive the collapse of the line into a pattern. 4. **Decision.** This step requires no configuration and is where most deployments never intervene. A pattern must prove itself genuinely repetitive before it is summarised, and volume alone is not proof: telemetry emitted once by each of many pods is treated as telemetry rather than as repetition. Errors, warnings and fatal levels are never suppressed by this mechanism. Suppression is further overridden by a pattern's first-ever occurrence, a rate spike, or a numeric value far outside the pattern's established range. Explicit customer rules are optional; where one exists it wins outright. 5. **Delivery.** Forwarded events go to the customer's SIEM in real time. Every event, including suppressed ones, is written to the customer's own object storage, compressed and in an open format readable with the customer's own tools, and indexed so that a later retrieval reads only the fraction of the archive that can contain matches. ## What a suppression summary contains A summary event carries the pattern, time window and count, plus the specifics: the distinct identifiers that appeared in the suppressed lines, such as request IDs, trace IDs, tenant IDs and addresses, and the distribution of any numeric field. It also carries a link that returns the original raw lines from the customer's own object storage. The repetition is lost; the detail is not. ## Data boundary Never leaves the customer's account: the full raw stream, indexed, in the customer's own bucket, object storage credentials, every line of every summarised pattern, the values extracted from those lines including the ones an anomaly was raised on, and everything forwarded to the customer's SIEM, which is delivered directly rather than by way of Auditty. Sent to the Auditty control plane: log templates with values masked, counts and rates and timing per pattern, and node and namespace and workload names. There is no exception for anomalies. When a pattern trips anomaly detection, whether a first-ever occurrence, a rate spike above its baseline, or a dormant pattern returning, what is sent is the same masked template plus the rate before and after. That identifies the pattern and is enough to alert on; it is not a sample of the customer's logs. Reading the lines behind an alert is a retrieval the customer requests, served from their own bucket by a component running in their own account. Nodes have no outbound internet route. They communicate with a single in-cluster service, which is the only component with egress. When the control plane needs archived data for a retrieval the customer requested, it asks that service, which reads from the customer's bucket locally and returns only matching rows. --- # Pages ## Home https://auditty.ai/ What Auditty does and why keeping all of the data changes how aggressively you can reduce what you forward. ## Platform https://auditty.ai/platform The five on-node stages a log line passes through: interception, classification, field extraction, an automatic decision you can override, and delivery to both your SIEM and your own indexed archive. ## Security and architecture https://auditty.ai/security Where the data boundary sits, every privilege the DaemonSet needs and why, the behaviour in each failure mode, and release provenance. ## Pricing https://auditty.ai/pricing Licensing on ingested volume, plus a calculator for the ingest cost you would stop paying and the object storage cost of retaining 100% of the raw data. ## How Auditty compares https://auditty.ai/compare Auditty against Grepr, Cribl, Edge Delta and Datadog’s own cost controls, with every claim about another product quoted from their documentation and every page naming where they are the better choice. ## Auditty vs Grepr https://auditty.ai/compare/grepr Both reduce log volume by pattern and keep the raw data. Grepr processes it in Grepr’s AWS account; Auditty processes it inside your own infrastructure. Sourced from both vendors’ own documentation. ## Auditty vs Cribl https://auditty.ai/compare/cribl Cribl gives you the tools to express what to drop. Auditty decides per pattern with no rules written, and keeps every line in your own bucket. Sourced from Cribl’s own sizing, pricing and Lake documentation. ## Auditty vs Edge Delta https://auditty.ai/compare/edge-delta Both put an agent on the node. Edge Delta is a full observability platform with its own backend; Auditty is one bounded agent that feeds the tools you already own. Sourced from Edge Delta’s own Helm and architecture documentation. ## Auditty vs Datadog’s own log cost controls https://auditty.ai/compare/datadog Exclusion filters, Flex Logs and Archive Search are good and often enough. What they do not change is the per-GB ingestion charge, because excluded logs are still ingested. Sourced from Datadog’s own docs and price list. ## AppsFlyer case study https://auditty.ai/case-studies/appsflyer AppsFlyer’s platform team replayed a peak hour of production traffic through Auditty in a segregated account before deploying it, then ran it across roughly 50 Kafka clusters and 1,000+ servers. 66% average suppression in evaluation, 50% sustained in production, published under their own name. ## Frequently asked questions https://auditty.ai/faq Direct answers on interception, suppression, retrieval, data handling, resource usage and licensing. ## Book a demo https://auditty.ai/contact Request a walkthrough against a sample of your own logs. ## Documentation https://auditty.ai/docs Installation, configuration, suppression and rule reference, the vault archive, metrics and access control. ## Platform Overview (documentation) https://auditty.ai/docs/overview What Auditty does to your logs, where it runs, and what reaches Auditty ## Installation (documentation) https://auditty.ai/docs/installation Deploy Auditty Edge on Kubernetes, Linux VMs, the CLI, or as a network (OTLP) proxy ## Configuration (documentation) https://auditty.ai/docs/configuration Edge settings, rules from the ConfigMap, annotations and the fleet, and shadow mode ## Log Intelligence (documentation) https://auditty.ai/docs/log-intelligence How Auditty distinguishes signal from noise: searchable ids in summaries, full originals in the Vault ## Suppression (documentation) https://auditty.ai/docs/suppression How Auditty reduces repetitive log noise ## Vault (Log Archive) (documentation) https://auditty.ai/docs/vault Archive suppressed log lines to cloud storage and recover them instantly ## Metrics (documentation) https://auditty.ai/docs/metrics Prometheus metrics for monitoring and observability ## User Management & Access (documentation) https://auditty.ai/docs/access SSO authentication, roles, and team onboarding ## Support (documentation) https://auditty.ai/docs/support How to get help and support ## Privacy policy https://auditty.ai/privacy How Auditty handles visitor, demo-request and platform administrator data. --- # Frequently asked questions ## The basics ### 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, compressed and indexed, 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. Source: https://auditty.ai/faq#what-is-auditty ### 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. Source: https://auditty.ai/faq#different-from-sampling ### 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. Source: https://auditty.ai/faq#does-it-delete-logs ### What log formats does Auditty support? Auditty handles plain text, JSON and logfmt. Deeply nested JSON is understood, including awkward real-world shapes: keys that contain literal dots, flattened ECS-style fields, and arrays whose contents vary from line to line. No schema declaration or parser configuration is required. Auditty works out the structure of each line for itself, and recognises a repeated shape in microseconds. Source: https://auditty.ai/faq#log-formats ### Does Auditty work outside Kubernetes? Yes. Auditty ships a systemd service for bare virtual machines in addition to the Kubernetes DaemonSet, and a command-line tool for batch-processing log files directly. Kubernetes is the primary production deployment; the others apply the same classification and archiving to ordinary log files. Source: https://auditty.ai/faq#outside-kubernetes ## How it works ### How does Auditty intercept container logs? On the node, where each container’s standard output lands, without anything being inserted between your workload and your logging. Your container runtime is unaffected and needs no reconfiguration: it goes on writing exactly as before, unaware that Auditty is there. Your existing log shipper also needs no change. It keeps reading the node’s logs as it always did, and now finds the reduced stream there. Because nothing new sits in the network path and no sidecar is injected, Auditty cannot become a new reason logs stop flowing. Source: https://auditty.ai/faq#how-interception-works ### Does Auditty add latency to my applications? No. Auditty never sits in the request path of your application, and it does not touch the write path your container uses to emit logs. Your workload writes its logs exactly as before, at exactly the same speed. Auditty reads asynchronously, after the line has already been written. Processing is sub-millisecond per line, but even if it were slower it could not delay the process that wrote the line, because that process has already moved on. Source: https://auditty.ai/faq#added-latency ### How does Auditty decide what to forward and what to suppress? In almost all cases, automatically and without configuration. A pattern has to prove itself genuinely repetitive before Auditty will summarise it, and volume alone is not proof: a message emitted once by each of two hundred pods is treated as telemetry, not as noise. Errors, warnings and fatal levels are never suppressed automatically at all. Three things additionally override automatic suppression: the first time a pattern is ever seen, a sudden spike in a pattern's rate, and a value far outside the established range for a numeric field you opted to track. So a single anomalous request still reaches you even when the pattern it belongs to is being summarised. Explicit rules are optional and exist for the two decisions statistics cannot make for you: which workloads the agent may read at all, and the specific patterns where you want to overrule the result. Where a rule exists it wins outright: a line you marked preserve is never suppressed by any automatic mechanism. Source: https://auditty.ai/faq#how-it-decides ### When Auditty suppresses thousands of lines, what do I actually receive? You receive a summary event carrying the pattern, the time window, the count, and the specifics: the actual distinct identifiers that appeared in the suppressed lines, such as request IDs, trace IDs, tenant IDs and IP addresses, together with the distribution of any numeric field, so you can see the spread of latencies rather than only that there were some. You lose the repetition, not the detail. The summary also carries a link that resolves back to the original raw lines in your object storage, so the full text of any suppressed line is one click away. Source: https://auditty.ai/faq#what-is-in-a-summary ### Can I get suppressed logs back later, and how fast? Yes, in seconds, and without scanning the archive. Every suppression summary links to the raw lines behind it, and following that link returns the actual log lines. The archive is indexed so that a retrieval reads only the small part of it that can contain matches, however large the bucket has become. You can narrow a retrieval to a single field, such as a latency above a threshold or one specific tenant, and only matching rows are returned. Retrieval also covers the present moment: data too recent to have reached storage is still returned, so there is no blind spot over the last few seconds. Source: https://auditty.ai/faq#can-i-get-logs-back ### How much CPU and memory does the Auditty agent use? In steady state, 60 to 80 MB of memory per node. The agent also ships with an enforced ceiling of 768 MiB and 1.5 vCPU, which it cannot exceed however much log volume you put through it, so the typical figure is what you should expect and the ceiling is what protects you if you are the exception. That headroom exists for sustained back-pressure, where the worst case we size for is around 420 MB, rather than for normal operation. Consumption is flat with respect to log volume rather than proportional to it, so a tenfold burst in logging does not become a tenfold burst in the agent, and it does not degrade into unbounded growth when a cache or buffer fills. Both figures are the defaults in the Helm chart, and you can lower them. On a high-pod-density node the guidance goes the other way: raise the ceiling or reduce the event buffer. Source: https://auditty.ai/faq#resource-usage ## Security and data handling ### Is Auditty SOC 2 compliant? Yes. Auditty holds a SOC 2 Type II report covering the Security trust services criteria. The examination period ran a full twelve months, from April 1, 2025 to March 31, 2026, and the report is dated April 16, 2026. Decrypt Compliance tested 52 controls and noted zero deviations. A point-in-time Type I report preceded it in December 2024. The full report is available on request, under NDA. It contains the description of the platform, every control tested, and the result of each test. Penetration test and disaster recovery test reports are available alongside it. The examination covers the Auditty Platform, meaning the control plane. Your object storage sits outside its scope by design: the archive is written by your own agent into your own bucket, using credentials you issue and Auditty never holds. Source: https://auditty.ai/faq#soc2 ### 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. Source: https://auditty.ai/faq#does-auditty-see-my-logs ### Does Auditty need access to my cloud storage credentials? No. Auditty's control plane holds no credentials for your object storage and has no network path to it. The archive is written by your own agent, running inside your own account, using credentials you issue and can revoke without involving Auditty. When the control plane needs archived data because you requested a retrieval, it asks a service running inside your cluster, which reads from your bucket locally and returns only the rows matching your request. There is no cross-account role to grant and no vendor access to review. Source: https://auditty.ai/faq#cloud-credentials ### Does Auditty run as a privileged container? No. It runs with two scoped Linux capabilities, DAC_READ_SEARCH and SYS_PTRACE, rather than in privileged mode. Reading other containers’ output does require host-level access, and those two capabilities are the whole of what that takes. Concretely, the agent needs read and write access to the node's container log directory, so that it can intercept each container's output and put the reduced stream where kubectl logs and your log shipper already read, and read-only access to process information on the host, so that it acts only on containers that are running. Auditty does not exec into containers, read application memory, modify workloads, or touch logs for pods outside the rules you wrote. A container Auditty was not asked to handle is left alone. Source: https://auditty.ai/faq#why-privileged ### Where is my log data stored, and for how long? Your log data is stored in your own Amazon S3, Google Cloud Storage or Azure Blob Storage bucket, under a prefix you choose, compressed and partitioned by time in an open format your own tools can read. Auditty never holds a copy. Retention is whatever your own bucket lifecycle policy says, because it is your storage and your billing relationship. Auditty applies no retention limit and takes no storage margin. Source: https://auditty.ai/faq#where-is-data-stored ### What happens to my logs if Auditty crashes or is removed? Your logs keep flowing. Restoring your log pipeline is the very first thing Auditty does on the way out, ahead of any of its own cleanup, so the file your log shipper watches is working again within milliseconds, before the process has finished exiting. After an abrupt kill or a node reboot there is nothing to repair by hand either: the same restoration happens automatically, in milliseconds, and removing Auditty entirely leaves your logging exactly as it was before you installed it. If the connection to the control plane fails, nodes continue running the last rule set they successfully validated; an empty rule set is never synthesised from a failure. If your object storage becomes unreachable, suppression stops automatically, so events are forwarded rather than summarised into an archive that is not accepting writes. You get a larger bill rather than a gap in your data. Source: https://auditty.ai/faq#if-auditty-fails ## Running it ### How long does it take to deploy Auditty? Auditty installs as a single Helm release and begins classifying logs immediately with its built-in pattern recognition, before you have written any rules. There is no schema to define, no parser to configure and no queue or collector tier to provision. Rules can then be added incrementally as you learn which patterns dominate your volume. Because nothing is destroyed, an over-aggressive rule costs a retrieval rather than lost data, so tuning is low-risk. Source: https://auditty.ai/faq#how-to-deploy ### How do rule changes reach the fleet? A rule saved in the Auditty control plane reaches every node in roughly one second, without polling delay and without a steady stream of background requests when nothing is changing. Rules are re-validated on each node and applied all-or-nothing, so a malformed payload cannot partially update a node. Each node reports which rule version it has applied and why it is stuck if it is, so fleet convergence is something you observe rather than assume. Source: https://auditty.ai/faq#rule-propagation ### Can a central team override rules a cluster owner depends on? No. A rule defined locally on a node shadows a fleet-wide rule of the same name, so the local definition is authoritative. This prevents a platform team from silently changing behaviour that a cluster owner relies on. Shadowing is reported upward rather than hidden: the Fleet Rules view shows which nodes are overriding which rules, and with what local action, so the central team can see exactly where its policy is not in effect. Source: https://auditty.ai/faq#local-vs-fleet-rules ### 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. Source: https://auditty.ai/faq#replace-my-siem ### Does Auditty detect anomalies on its own? Yes. Auditty flags the first occurrence of a previously unseen log pattern, sudden spikes in the rate of a known pattern, numeric values that fall far outside a pattern's established range, and previously unseen values on low-cardinality categorical fields. These are computed on the node, so they cost no additional infrastructure and there is nothing extra to run. They surface in the control plane and, critically, they override automatic suppression: a novel or anomalous event is forwarded even when its pattern is otherwise being summarised. Source: https://auditty.ai/faq#anomaly-detection ## Cost and licensing ### How is Auditty priced? Auditty is licensed on ingested volume, meaning the bytes the agent reads on the node, and quoted in annual tiers so the rate falls as volume rises. We meter what we read rather than what we forward, so tightening your rules cuts your log vendor bill without changing what you pay us. Node count, pattern volume, rule count, retrieval count and forwarder types are not billing levers, because high cardinality is the problem customers arrive with and metering it would penalise them for it. Object storage is billed by your cloud provider directly to you. Auditty never holds your data, so there is no storage or egress margin in between. Source: https://auditty.ai/faq#pricing-model ### 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. Source: https://auditty.ai/faq#how-much-savings ### Can I just use my log vendor’s exclusion filters instead? Sometimes, and when that is true you should. If the waste is a handful of known, stable patterns, your vendor’s own exclusion filters will remove them for free, in minutes, and no upstream tool is worth buying for that. Try that first. What an exclusion filter cannot change is the ingestion line. Datadog, for example, bills ingestion per GB on everything you send and bills indexing separately; a log excluded from an index is still ingested and still charged. Auditty summarises the repetitive line on the node, so it is never sent, never ingested and never billed, while the full line stays in your own bucket. If ingestion is the line that hurts, or the waste is thousands of shifting patterns rather than three, that is the case a filter inside the vendor cannot reach. Source: https://auditty.ai/faq#exclusion-filters-enough ### Does Auditty stop working if it cannot reach your servers? No. Auditty entitlements are cryptographically signed tokens verified locally on the node, so there is no phone-home licence check that can disable your log pipeline when Auditty's service has an outage. Nodes that lose contact with the control plane continue processing with their last validated rule set and keep writing to your object storage. Loss of the control plane costs you visibility and rule changes, not log processing. Source: https://auditty.ai/faq#licence-offline