Straight answers.

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.

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.

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.

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.

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.

On the node, at the file level, without anything being inserted into the path between your workload and its log file. 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 watching the same path it always did, and now finds the filtered stream there. Because nothing new sits in the network path and no sidecar is injected, Auditty cannot become a new reason logs stop flowing.

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.

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.

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 — request IDs, trace IDs, tenant IDs, 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.

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 — a latency above a threshold, 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.

The Auditty agent is capped at 1 vCPU and 256 MiB of memory per node, and those are enforced limits rather than recommended ones — the agent cannot exceed them however much log volume you put through it.

This means it cannot grow into the memory your workloads need during a traffic spike. 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.

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.

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.

Reading other containers' log files requires host-level access. The agent needs read and write access to the node's pod log directory, so that it can read the raw stream and write the filtered one back to the path your log shipper already watches, and read-only access to process information on the host, so that it acts on log files that are genuinely in use.

Auditty does not exec into containers, read application memory, modify workloads, or touch logs for pods outside the rules you wrote. Recovery of a damaged or deleted log file is scoped to pods matching an interception rule, so a log Auditty was not asked to handle is left alone even when it is visibly broken.

Your log data is stored in your own Amazon S3, Google Cloud Storage or Azure Blob Storage bucket, under a prefix you choose, as compressed Parquet partitioned by time. 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.

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.

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.

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.

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.

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.

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.

Auditty is licensed per node and quoted against your fleet size. 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.

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.

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.