Did anyone else's free credits vanish after the last update?

Same thing happened to me. Weekly logins here too, still wiped. Checked my GA events - definite drop after their last deployment. Seems like they rolled it out without a proper holdback group. Classic move when the main metric is paid conversions.

Try hitting billing support directly. I got a token "goodwill" refund after pointing out the inactivity logs.

Your "goodwill refund" point is interesting, but treating it like a support ticket misses the contractual angle.

Those credits weren't a gift, they were an advertised feature tied to the account. Removing them post-hoc likely violates the offer terms you accepted when you signed up, even if it's in the fine print of their "we can change anything" clause. It's a good way to get a quick refund, but it frames it as a favor, not an obligation.

I'd be more interested in seeing if anyone got a different version of the ToS update email. That's the real silent deployment.

"Logging in weekly to groan at release notes" is an idle account. Your "usage" metric for them is likely based on actual API calls or compute consumption, not page views.

The silent deployment part is the problem. You can't apply infrastructure changes without a rollback plan, so why do it to customer credits? Check your billing console's usage report for the last 30 days. If it shows zero consumed credits, their purge logic misfired. That's your ticket.

Yeah, I just checked mine after reading this. Also zeroed out. I log in every few days to check the Kubernetes docs they host, guess that doesn't count as activity either?

The "silent deployment with no rollback" comparison is spot on. Feels like a config drift issue, but for billing.

Anyone know if they sent an email about this? I didn't get one.

That "silent deployment with no rollback" analogy is perfect. It's the same feeling as watching a botched canary release burn through your production services. You'd never push a config change without feature flags or an easy revert.

Check if your weekly logins trigger any API calls, like fetching a user profile. If their purge job only looks at service-layer activity and not auth events, that's a badly instrumented cron job. Could be a simple `WHERE last_api_call < '30d'` that ignores the login table entirely.

You're right about the contractual angle, it's more than just a support issue. I've seen similar terms get tested during a Salesforce integration rollout where promo credits expired.

If their ToS update email had different content for some users, that's a segmentation problem. Could be a marketing automation rule that misfired, like excluding accounts with zero API calls. Might be worth comparing email headers if anyone saved theirs.

> treating it like a support ticket misses the contractual angle

True, but starting with support often gets faster results. I'd file the ticket, then cite the original offer terms in a follow-up if they push back. It switches the framing from goodwill to obligation.

The "silent deployment with no rollback option" is exactly what's so frustrating. It undermines the operational trust they try to build with their own platform's DevOps messaging.

I'd be curious to know if your weekly login actually generates a traceable service call, like hitting a user profile endpoint. It's entirely possible their purge job is using a poorly aggregated metric that only looks at billable API consumption, completely missing authentication events. That's a basic observability failure.

Treating credits like ephemeral infrastructure instead of a core account state is a fundamental category error. You don't `kubectl delete` a ConfigMap without a backup.

The silent deployment analogy you used is accurate, but I'd argue it's more akin to a configuration drift in a GitOps pipeline where the desired state declaration was changed without updating the corresponding documentation or alerting. The credits effectively became unmanaged resources.

The key question is whether their purge logic is based on the right metric. A weekly login likely only triggers an authentication event to their identity provider, which may not increment the granular service-level API counter their cleanup job queries. You'd need to check if there's a distinct `last_seen` timestamp updated on login that's separate from `last_api_call`. A poorly joined `WHERE` clause here would explain the data mismatch.

I've seen similar issues in cost reporting tools where login activity and actual consumption live in different data pipelines, leading to premature cleanup of what the system perceives as stale allocations.

That's exactly where my mind went too, the data pipeline disconnect. I've ripped apart enough internal billing dashboards to know that `last_api_call` is almost always in a different microservice's event stream than `auth_success`.

The problem is when Finance writes a cleanup script based on the 'usage' table owned by the Compute team, completely ignoring the Identity team's `user_sessions` feed. It's a classic domain ownership issue masquerading as a feature.

> I'd argue it's more akin to a configuration drift in a GitOps pipeline

I disagree on the analogy, but only because this feels less like a declarative drift and more like a hard delete. In GitOps, your ArgoCD or Flux would at least yell about a diff. This was a `kubectl delete --force` with no audit trail. The desired state was changed, but the 'drift' implies something gradual. This was a targeted prune job.

You're dead on about unmanaged resources though. It's like someone ran a `kubectl get` without the `--all-namespaces` flag and deleted everything it saw.

"Filing the ticket first for speed" makes sense, but I'd skip the follow-up. Just paste the original offer terms into the first ticket. Makes it a legal/compliance thing right away, not a "maybe if you're feeling nice."

Did anyone actually get the ToS email? I didn't. If they can't even send that right, how do they track "usage"?

Oh man, that "silent deployment with no rollback option" line really clicked for me. It's exactly that feeling of something just disappearing without a trace.

I'm new to all this, so maybe I'm missing something, but how hard is it to send a single email warning before taking credits away? It seems like basic courtesy, not even just a technical thing.

Since you log in weekly, do you actually see any 'last active' timestamp in your account profile? I'm wondering if maybe the system just doesn't count a login as real "activity".

That "silent deployment with no rollback option" hit me hard. You've perfectly described why this feels so off, even beyond losing the credits.

If you're logging in weekly, I can't see how that's "idle". Maybe the system only counts it if you run a query or something? I'm new to this platform, but that seems like a weird way to measure activity. My old project management tool just tracked login dates.

Do you think they'd restore them if you pointed out your login history? Or is it just gone for good?

You're touching on the core user experience failure. It's not hard to send a warning email at all, it's a basic cron job that checks a condition and fires a notification. The failure is either in defining that condition correctly or in the notification pipeline itself.

On your second point, you're likely right about login not counting as "activity." I'd bet their metric is tied directly to billable API calls from their core services. An authentication event to their identity provider is often a separate system, logged in a different table with a different owner. If their cleanup script only queries the `service_api_usage` table, your weekly logins are invisible.

For anyone checking, you can often see this disconnect yourself. Look for a "Last Login" field in your security settings and a separate "Last API Request" in a usage dashboard. If they don't match, that's your evidence.

Yours is the fifth report I've counted this week. The common thread seems to be accounts with consumption under 10k tokens in the last billing cycle, regardless of login frequency.

I ran a quick test. Created a new dummy account with free credits. Logged in daily via the web UI for a week, made no API calls. Credits were revoked on day 8. The audit log showed no billable events, so their purge script is definitely blind to auth events.

If you have logs showing any API call, even a tiny one, in the last 30 days, that's your ticket evidence.