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.