Datadog's startup credit runs on a countdown, not a pricing tier. While the credits last, the bill reflects a number chosen to get a startup in the door, not what actual usage costs at list price. When that clock hits zero, nothing about the architecture changes overnight, but the invoice does, and it exposes a cost model and a retention setup the team never had to think hard about while the discount absorbed the difference.
The subsidized year has a fixed expiration date
Startup credit programs are built around a defined activation step and a hard stop. Public program materials describe participation as lasting about a year from activation, or until the credit pool is exhausted, whichever comes first. After that, billing reverts to standard rates. There's no soft landing built in: the credit either runs out on the calendar or gets consumed early by usage growth, and either way, list-price billing starts that day, not gradually.
The program is working exactly as intended, not malfunctioning: get a startup fully instrumented on the platform during the year it's least likely to push back on architecture decisions, then convert it to a paying account once its usage patterns, and its dependency on the tool, are set. Founders approaching that date are often looking for a path out before the invoice tells them they need one.
What changes when the discount disappears
Legacy log-management pricing typically separates two costs that a subsidized account never forces you to distinguish: what it costs to send data in, and what it costs to make that data searchable once it's there. A team can be paying a real ingestion fee on every log line while a separate indexing charge determines what's actually queryable in the standard, fast-search tier. During the credit year, both numbers get absorbed into "free." Once the subsidy ends, they're two separate levers, and most teams don't know which one is driving the increase because nothing ever asked them to look. Our bill spells out how we bill loading, query, and storage as three distinct, always-visible meters, so there's no guessing which one moved once volume grows.
Per-host and per-GB pricing compounds with everything that grew during the free year specifically because nothing was metering it closely: more services, more instrumentation depth, more team members adding tags and dashboards. None of that growth was reckless. It's what a free year is designed to produce. But it means the bill that arrives after the credits expire reflects a footprint that was never sized against a real budget.
The choices teams make under a shrinking budget, and what they cost later
Faced with a bill that's suddenly multiples of what it was, most observability stacks reach for the same three levers: sample events to cut volume, shorten retention windows to cut storage, and drop high-cardinality tags to cut both ingestion and indexing cost at once. This is the standard response to a cost model that only lets teams turn dials on volume. It isn't a mistake any one engineer made.
The problem is what those dials quietly throw away. High cardinality exists because real infrastructure produces real variation (different devices, different customer segments, different edge cases), and sampling doesn't know in advance which of those variations will matter. Our take on high-cardinality metrics without the cost is built on the same premise: the variation is the signal, not noise to be trimmed. The edge-case evidence that sampling discards is evidence you need later: the one device that behaves differently, the slow-and-low attacker who deliberately generates events they know get sampled out, the customer segment dashboards weren't tracking. You don't find out what you needed until the moment you need it, and by then it's already gone.
Retention and the rehydration tax
The other lever, shortened retention, runs into a structural pattern common to legacy log platforms: a cheap, cold archive tier that isn't always directly queryable on its own. Historically, and still by default on most setups, searching data that's aged into that tier has meant restoring it into a hot, indexed tier first. That restore step takes time and often carries its own cost on top of whatever indexing fee applies once the data is back. A few platforms have since added narrower search-in-place options for archived or frozen-tier data, but for any team that hasn't specifically configured that capability, the underlying tradeoff hasn't changed. That trade is reasonable when the data is cold, but it turns ugly during an incident, when "give me the logs from three months ago" becomes a support ticket instead of a query.
This is the tradeoff a subsidized year never makes visible. When ingestion, indexing, and storage are all inside a credit pool, you never have to decide how much of last quarter's data needs to stay instantly searchable versus how much can wait behind a restore step. Once the bill is real, that decision gets made under pressure, typically by shortening the window before data goes cold rather than by rethinking whether cold-and-slow was the right model at all.
We treat retention as a plan-based, configurable setting, not a tier boundary that changes whether data is queryable. Dataset retention is set in console, per dataset, rather than by moving data into a colder SKU. Teams can also set a monthly spending limit directly rather than discovering the number after the invoice arrives. And because every event stays queryable for as long as you keep it, there is no rehydration step between "stored" and "searchable."
The credit cliff makes this a switch decision
A team that's just spent a year on a subsidized platform often assumes the fix is smaller usage, not a different vendor. But the credit cliff exposes something the subsidy was hiding: a pricing model built around list-price rates that were never tested against actual traffic, and a retention and cardinality strategy that was never tested against a real incident.
Our pricing uses usage-based rates with automatic volume discounts, structured so the rate you pay per GB starts lower and stays lower as volume grows, rather than starting subsidized and reverting to list price on a fixed date. That's the point behind our approach to pricing: pay only for what you use, with no promotional year standing between your usage and your bill.
For a startup that scaled its logging, tracing, and metrics footprint during a subsidized year, the real question isn't how to shrink that footprint back down. It's whether the pricing model was ever built to hold the shape you're already in. Our path from first TB to first PB is built for exactly that trajectory, without a credit cliff after a subsidized year.
FAQs
Public program materials describe about a year from activation, or until the credit pool runs out, whichever comes first. After that, billing reverts to standard rates.
Costs that sat inside the subsidy, especially ingesting logs and making them searchable, become separate, visible line items. Most teams also discover a retention tradeoff they never had to make while the discount absorbed the difference.
Loading, query, and storage are three meters on the usage and billing page, with usage-based rates and automatic volume discounts after the Always Free allowance. Retention is configurable per dataset, not a restore from a cold archive.
Yes. A monthly spending limit is set in console; usage beyond the limit is paused rather than auto-billed.
Related Reading
See what your current usage would cost on Axiom
The fastest way to answer the "now what" question is to run your actual ingestion, indexing, and retention numbers against a pricing model that doesn't depend on a subsidy. Get a demo and bring your current Datadog bill. We'll show you what the same data footprint costs without a credit countdown attached to it.