Hey folks, been running Traceloop in our EKS setup for a few months now to trace our LLM calls. Really liking the insights, but I’ve hit a snag with their data retention policy that’s got me scratching my head.
The docs say traces are kept for 30 days, which seems straightforward. But I noticed some trace data lingering in our system *past* that mark when I was doing some cost analysis on our OpenSearch ingestion. It wasn't a huge amount, but enough to make me wonder if I'm misunderstanding the cleanup cycle.
Has anyone dug into the actual deletion mechanics? Is it a hard delete at 30 days from ingestion, or is there a rolling window based on when you first set things up? Also, I saw references to "aggregated metrics" being kept longer—does that mean parts of my trace data are transformed and stick around indefinitely unless I tweak something?
Here’s a snippet of our collector config. I don't see any explicit overrides, so I assumed defaults apply.
```yaml
exporters:
traceloop:
endpoint: "https://api.traceloop.com"
api_key: "${TRACELOOP_API_KEY}"
```
Would love to hear if others have run into this. Trying to keep our observability costs predictable, and unexpected data retention is always a sneaky one. Maybe there's a dashboard or API call to see what's scheduled for deletion that I've missed?
cost first, then scale
Ah, the classic "data is deleted, but maybe not really" policy. I've been down this road with other vendors.
Your config snippet is using the default exporter, which likely means you're subject to their backend pipeline. The 30 days is almost certainly a *policy* applied by their scheduled jobs, not a hard TTL at the ingestion point. If their cleanup job runs weekly and only processes data older than 30 days, you'll see a tail of 30-37 day old data until the next run. That could explain the linger.
But the aggregated metrics bit is the real kicker. Yes, parts of your trace are absolutely being shredded, aggregated, and stored in a separate time series for "insights." That's the whole business model. You're not paying just for storage, you're paying for the derivative data products they build from your traces. Those likely have a much longer, or even indefinite, retention unless you're on an enterprise plan with a custom agreement.
Did you check if the lingering data is raw span/event detail, or is it just the aggregated counts and latency metrics that get pushed to your OpenSearch? That's usually where the cost surprise comes from.
Data skeptic, not a data cynic.
Spot on about the derivative data. It's the silent upcharge.
They all do it. The aggregated metrics become the "valuable insights" they pitch for upsells. That's why you can't delete them yourself, even though it's your data.
Weekly cleanup job is generous. More likely a monthly cron that misses its window half the time. Hence the linger.
Just my two cents.
Oh man, this hits close to home. I've been through this exact scenario with other SaaS platforms, especially in marketing automation where "deleted" data sometimes feels like a suggestion more than a rule.
You're asking exactly the right question about the difference between a policy and a hard TTL. In my experience, that "30 days" is a target for their scheduled cleanup job, not a real-time countdown timer on each trace. If their job runs on the 1st of every month and your data hit day 31 on the 2nd, it sits there until the next cycle. That's probably the "linger" you're seeing.
And yeah, the aggregated metrics thing is the real curveball. They often consider that processed, derivative data, which falls under a different, much longer retention policy. It's frustrating because you can't easily opt out, and it can feel like your raw data is living on in another form. I'd check their terms of service for the phrase "anonymized" or "aggregated" data retention. That's usually where they hide those details.
don't spam bro
The config snippet is meaningless for retention. You're using their SaaS endpoint, so the policy is entirely enforced on their backend. You have zero control.
You're right to be suspicious. The "cleanup cycle" you're asking about is almost certainly a batch job that deletes data *older than* 30 days, not data *that turned* 30 days old today. That's why you see a tail. The job might run weekly, or only when storage thresholds are hit. It's never a real-time TTL.
The aggregated metrics are a separate data product derived from your raw traces. They're stored in a different system, often a time-series database, with its own, much longer, retention policy. That's the part they consider "the insights," and it's why some fingerprint of your data persists. You'd need to ask their support for the specific policy on that derived data, but expect it to be measured in months or years, not days.
You've hit on the critical distinction between a retention *policy* and a retention *mechanism*. The 30 days is a policy goal; the mechanism is almost always a batch cleanup job.
In my AWS cost work, I see this pattern constantly. The "linger" you're observing directly translates to unexpected storage costs. If their job runs weekly, you're paying for up to 37 days of data, not 30. That's a 23% cost overhang against the stated policy.
>aggregated metrics being kept longer
This is typical. They'll often argue the aggregated data (e.g., p99 latency, error rates) is a "new" derived work, not your raw trace, so it falls under a different, perpetual license. You should ask support for the specific retention policy document for each data *type* they store. The raw span storage is one line item; the metrics are another.
Right-size or die
Yeah, that config snippet is using their managed backend, so the 30 days is definitely a soft policy on their side, not a TTL on your data. I've seen this cause cost spikes too.
For the aggregated metrics, you're spot on. The raw spans might get cleaned up, but the derived metrics for dashboards and alerts are often kept much longer, sometimes indefinitely. It's a separate data product in their system.
You might want to check if they have a self-hosted option. That's the only real way to enforce a hard delete schedule yourself. Otherwise, you're at the mercy of their batch jobs.
measure twice, ship once
The OpenSearch cost analysis is the tell. You're seeing the financial artifact of their batch cleanup, not a misunderstanding. Every day of "linger" past 30 is a direct storage cost you're still paying for.
That config snippet points to their managed backend, so you're right to assume defaults. The aggregated metrics are the real cost anchor. They're not a tweak you can make; they're a derived data product with its own, usually permanent, retention. Ask their support for two separate policy documents: one for raw trace storage, one for aggregated metrics. The difference in those SLAs is where your cost predictability disappears.
Spot on about checking the cleanup cycle. Odds are it's a monthly cron job, not a daily one. So you get a 30-60 day rolling window, not 30.
- elle
Exactly right on the cost angle. It's the difference between the policy doc and the actual bill.
Your point about two separate SLAs is crucial. I've had to chase down that exact split with other vendors. The raw trace SLA is often just for the blob storage, while the aggregated metrics live in their analytics engine with a "standard" retention that actually means "forever unless you negotiate." That's where your cost predictability evaporates.
Monthly cron job feels generous, honestly. I've seen quarterly cleanup cycles for some "archival" data. Makes you wonder if the 30-day window is just an average over the year.
Cheers, Henry