Auditty vs Datadog’s own log cost controls
This is the one comparison where the answer is frequently "you already have what you need". Datadog’s cost controls are better than the competitive folklore about them, and if your waste is concentrated in a few known patterns you should go and use them right now, for free, before talking to anyone.
Auditty sits upstream of Datadog rather than against it. So the useful question is not which is better, it is which line of your invoice you are trying to move.
Exclusion filters move the indexing line. They do not move the ingestion line.
Datadog bills ingestion per uncompressed GB and indexing separately per million events, and a log excluded from an index is still ingested. That is the gap Auditty closes, because a line that was summarised on the node was never sent and so was never ingested. If your bill is mostly indexing, Datadog’s own tools are the cheaper fix and you should use them. If your bill is mostly ingestion, no filter inside Datadog can reach it.
Side by side
5 questions a buyer actually asks.
Every claim about Datadog below is a quote from their own documentation, with the link. We would rather you checked than took our word for it.
Does an exclusion filter reduce what I pay to ingest?
Auditty
A suppressed line is never forwarded, so it is never ingested and never billed. The line still exists, in full, in your own bucket.
Datadog
Excluded logs are removed from the index but are still ingested, and ingestion is charged per ingested GB. That is not a criticism of the feature, which is doing exactly what it says.
However, these logs are only excluded from indexing. They are still ingested and available to view in Live Tail and can be sent to log archives or used to generate metrics.
How much effort is it to keep the filters right?
Auditty
None by default. Suppression needs no rules, and rules exist to scope which workloads are read and to override the automatic decision rather than to keep the savings alive.
Datadog
Filters are authored per index and ordered, with Datadog’s pattern view able to prefill the query. Worth knowing before the list grows: only the first matching filter applies.
Index filters for logs are only processed with the first active exclusion filter matched. If a log matches an exclusion filter (even if the log is not sampled out), it ignores all following exclusion filters in the sequence.
Can I search the archive without paying to index it again?
Auditty
Yes. Retrieval reads your own storage by pattern, time range or field value, and nothing is written back into your log vendor to be searched.
Datadog
Yes, and this changed recently enough to be worth restating: Archive Search queries object storage in place. It returns a results page rather than full platform access, so aggregations, dashboards and monitors still mean rehydrating.
No aggregations or analytics: You cannot run aggregations, create visualizations, or perform advanced analytics directly on Archive Search results. Results page only: Archive Search results are only available in the dedicated results page and cannot be queried from other parts of the Datadog platform (such as Dashboards, Notebooks, or Log Explorer).
What does it cost to pull an old log back?
Auditty
A lookup. Retrieval does not re-ingest, so getting a line back does not add to the bill you installed Auditty to reduce.
Datadog
Rehydration is billed on everything scanned for the time window rather than on what matched your query, plus indexing for whatever comes back. Narrowing the query does not narrow the scan.
The query is applied after the files matching the time period are downloaded from your archive. As a result, the rehydration scan size is based on the total volume of logs retrieved from the archive, not the number of logs matching the query.
Where does Flex Logs fit?
Auditty
Alongside it, not against it. Auditty decides what reaches Datadog at all; Flex decides how cheaply Datadog holds what does.
Datadog
Flex is dramatically cheaper per event than standard indexing and is the right tool when the requirement is retention rather than reduction. The trade is stated plainly in their docs.
Monitors are not supported in Flex Logs. Watchdog is not supported in Flex Logs.
Honestly
Neither of these is the right answer for everyone.
Use Datadog’s own tools and add nothing if
- Your waste is concentrated and stable. Three chatty patterns accounting for most of the volume is a problem Datadog’s pattern view will find and fix for free, in about ten minutes, with no new vendor.
- Your bill is mostly indexing rather than ingestion. Moving logs to Flex is a far larger saving on that line than anything upstream can do, and the data stays correlatable with your metrics and traces.
- The requirement is long retention for audit or compliance. That is a storage-tier problem, and dropping data upstream is the wrong answer to it.
- Your volume is modest enough that a percentage of the bill does not cover the cost and operational load of running another component.
Add Auditty if
- Ingestion is the line that hurts. It is charged on everything you send, and no filter inside Datadog reaches it.
- The waste is not concentrated. When it is thousands of patterns rather than three, authoring and maintaining filters stops being a ten-minute job and starts being somebody’s week, repeatedly.
- You want the full-fidelity copy in your own bucket, retrievable without re-indexing it into a vendor to read it.
- You want to keep Datadog. Auditty forwards to it directly and changes nothing about how your dashboards, monitors and alerts work.
Datadog's documentation was read on 3 September 2026, and every quote above links to the page it came from. Products change, and a comparison page that is not re-read is a slow way of becoming wrong. If something here is out of date or unfair, tell us at [email protected] and we will correct it.
About Auditty
The questions this raises about us.
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.
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.
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 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.
The fastest way to settle this is your own logs.
We will run a sample of them and show you what would have been forwarded, what would have been summarised, and what it would have cost.