Log Archive

Overview

A Log Archive is the mechanism that forwards the logs Datadog ingested to the user's own storage, such as Amazon S3, Azure Storage, or Google Cloud Storage, and stores them as compressed JSON. Because logs excluded from indexes are also covered, you can keep the logs themselves on hand even if you shorten the searchable period. When you later want to investigate, you specify a period and a query, rehydrate, and bring the logs back to a state where they can be searched in Log Explorer. The situations where it matters are when audits or regulatory compliance require long-term retention, and when you investigate an incident after the fact once the retention period has passed. Cost is determined by the storage-side fees plus the volume scanned and the volume re-indexed when bringing logs back.

Where logs that do not stay in an index go

A Log Archive is a setting that forwards the logs ingested into Datadog to your own cloud storage, regardless of whether they entered an index. The official documentation describes this mechanism as keeping logs for a long time in a storage-optimized location, meeting regulatory and audit requirements while keeping them available for re-examination when needed (as of September 2026, Source: Log Archives). A Log Index is a location for search, and logs disappear once the Retention period has passed. An archive is the location outside of that, meant for not deleting. Because logs dropped from indexes by exclusion filters are forwarded too, you can set up an operation that narrows the search scope to hold down cost while never discarding the originals.

The fork after ingestion - indexes and archives are separate paths

After an ingested log has been processed by pipelines, its path splits in two. One is the path into an index, where it becomes searchable; the other is the path to be forwarded to an archive. The two are independent.

The volume of logs successfully forwarded can be tracked with the metrics datadog.archives.logs.bytes and datadog.archives.logs.count (as of September 2026). Having a way to confirm that forwarding has not stopped is an important point for a mechanism you entrust your originals to.

Three destinations, one order

The destinations you can choose are Amazon S3, Azure Storage, and Google Cloud Storage (as of September 2026). Configuration requires the integration for the target cloud, a bucket, and permissions for Datadog to write, and only users with the logs_write_archive permission can operate it. The procedure itself is left to the official documentation and the explanation of Log Management. You can define multiple archives, and a log goes into the first archive whose conditions it matches. If you place an archive filtered by env:prod first and an archive with no conditions after it, you can separate production logs and the rest into different buckets. If you reverse the order, everything goes into the unconditional one, so the ordering is part of the design. The storage format is compressed JSON, with zstd .json.zst as the default and gzip also available. Files are placed in directories split by date and time.

Two paths for reading - Archive Search and rehydration

There are two paths for reading logs in an archive. The one the official documentation recommends is Archive Search, which searches the archive directly without re-indexing, and billing is only for the volume scanned. When you want to use logs with all features or keep them for longer, you use rehydration, which brings them back into Log Explorer, which is optimized for search. Rehydration is run in units of a "historical view" with a specified period and query; up to 1 billion logs can be brought back per run, and exclusion filters are not applied (as of September 2026, Source: Rehydrating from Archives). Only archives to which you have granted read permission, such as through S3 role delegation, are eligible. Rehydrated logs are searchable for 15 days by default, and administrators can set an upper limit on the number of logs that can be brought back and the retention period options. The scanned volume is determined by the volume of all logs stored within the period, not by the number of matches (because the query is applied after retrieval). The official documentation states that cutting the period short is the most effective measure.

Cost is determined by the scanned volume and the volume brought back

Archive storage fees are paid to the cloud provider and do not appear in Datadog's price list. What is incurred on the Datadog side is the cost of reading. Rehydration has two components: a unit price on the GB of compressed data scanned, plus your contracted index unit price for the re-indexed logs. Archive Search incurs only the unit price on the GB scanned, with no index unit price (billing structure as of August 2026; Source: Datadog Pricing). This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page. How to read the unit prices is left to the entry on Retention and the explanation of log pricing; here we only cover what increases the volume. Idly bringing back a wide period increases cost through scanned volume, and bringing back a large amount with loose conditions increases it through index volume. If you set a maximum scan size per archive, runs whose estimate exceeds it are stopped, prompting you to narrow the period.

An archive is not an extension of retention

Setting up an archive does not extend the searchable period. Logs are searchable only while they are in an index, and logs in an archive become searchable only after you either read them directly with Archive Search or bring them back through rehydration. Bringing them back takes an operation and costs money, and the rehydrated logs get their own separate retention period. That is why an archive suits the role of a place for logs you cannot discard even though you do not know when you will need them. In situations such as an audit requesting a year of authentication logs, or wanting to trace the cause of an incident after the retention period has passed, you narrow the period and query and bring back only what you need. The basic approach is to do day-to-day investigation with indexes and Live Tail, and to position the archive as insurance.