Issues with Unexpected Credit Consumption and Request for Support on Clay Usage

Ignacio J. · 2026-01-24T12:44:19.322Z

Hi 👋 — quick context + help request. We’re a fund scaling outreach operations with Clay, and we’ve invested significant time/resources building core parts of our workflow on Clay. It’s been working really well overall, and we’re ready to keep scaling our usage — but we’re running into issues that are making it hard to reliably control credit spend. What’s happening: • We’ve had a couple of instances where credits were consumed unexpectedly because a column auto-ran. • In at least one of those cases, once the run started burning credits, the Stop button didn’t actually stop the action (it appeared to keep running/consuming credits). What we need help with: • Is there someone we can speak with privately (support/billing) to review what happened and confirm whether any credits can be restored? • Can someone advise on best-practice setup to prevent “full credit spending at once” (safer run patterns, settings to avoid auto-run surprises, etc.)? Happy to share the workspace/table + column details, timestamps, and anything else helpful. Thanks in advance 🙏

Issues with Unexpected Credit Consumption and Request for Support on Clay Usage | Clay

6 comments

· Sorted by Oldest

Clay Support
APP
·
·
I understand your concerns about credit usage and the difficulty with stopping runs. I’m connecting you to a human teammate now who can assist you further with this issue.
Clay Support
APP
·
·
Our support team has got your message and we'll get back to you soon! We're currently outside of our standard office hours (9 AM to 9 PM EST, Monday through Friday), so it may take a little longer for us to respond.

If you’re dealing with a specific table, drop the URL below so we can help you quicker. Otherwise, someone from our team will be in touch soon!

image.png(93 kB)
Bo (.
·
·
Hey Ignacio,
Thanks for the context, that helps.
On the credit behavior you’re seeing: this is expected with auto-running columns. When a column has auto-run enabled, any qualifying row updates will trigger it and start consuming credits. There isn’t a safeguard that pauses spend once it begins unless auto-run is turned off ahead of time.
About the Stop button: when you click Stop, Clay prevents new requests from being queued. Any requests that were already dispatched will still complete and consume credits since they were already sent to the provider. That’s why it can look like the run keeps going after you stop it.
For reviewing a specific incident or asking about potential credit restoration, please open a ticket via the question mark icon in the top right. That’s the right path to loop in support and billing privately. Share the workspace, table, column name, and timestamps so we can review accurately.
To avoid large, unexpected credit spend going forward:
Disable auto-run on expensive columns and run them manually
Use run conditions so columns only fire when inputs are complete
Test new enrichments on a small batch first
Avoid chaining auto-run columns unless necessary
These two docs go deeper on this:
https://docs.clay.com/en/articles/9642165-auto-update-and-auto-dedupe-table
http://www.clay.com/university/lesson/clay-credit-conservation
Let me know if you have more questions.
Ignacio J.
·
·
Thanks — that clarifies both auto-run spend and why Stop can appear to keep running. We’ll open a ticket now with workspace/table/column + timestamps for the incident review. Quick question: is there any way (or workaround) to add guardrails like a spend cap / confirmation prompt before an auto-run column dispatches at scale? We’re scaling high-volume workflows and want no surprises — happy to follow any recommended best-practice pattern for batching + run conditions to avoid accidental retriggers.
Andrew Q.
·
·
Hey Ignacio! As of right now, we do offer a few workbook level credit limits but it's available only on Enterprise plans. Our team are working to produce a few more features that will help with credit spend on the roadmap. As of now I would follow this framework to prevent credit burn:
Auto-Update controls - Turn off when not needed to prevent automatic refreshes
10-row testing - Test enrichments on 10 rows before running full tables
Run empty/error rows only - Avoid overriding existing data points
Sandbox mode - Build workflows without spending credits before going live
Clay Support
APP
·
·
We haven't heard back from you here, so we're going to go ahead and close this thread out.

Still need help here? Reply back and someone will jump back in.

Have a question thats not related to this thread? We recommend kicking off a new ticket in the support channel!

Clay Support
APP
·
·
I understand your concerns about credit usage and the difficulty with stopping runs. I’m connecting you to a human teammate now who can assist you further with this issue.
Clay Support
APP
·
·
Our support team has got your message and we'll get back to you soon! We're currently outside of our standard office hours (9 AM to 9 PM EST, Monday through Friday), so it may take a little longer for us to respond.

If you’re dealing with a specific table, drop the URL below so we can help you quicker. Otherwise, someone from our team will be in touch soon!

image.png(93 kB)
Bo (.
·
·
Hey Ignacio,
Thanks for the context, that helps.
On the credit behavior you’re seeing: this is expected with auto-running columns. When a column has auto-run enabled, any qualifying row updates will trigger it and start consuming credits. There isn’t a safeguard that pauses spend once it begins unless auto-run is turned off ahead of time.
About the Stop button: when you click Stop, Clay prevents new requests from being queued. Any requests that were already dispatched will still complete and consume credits since they were already sent to the provider. That’s why it can look like the run keeps going after you stop it.
For reviewing a specific incident or asking about potential credit restoration, please open a ticket via the question mark icon in the top right. That’s the right path to loop in support and billing privately. Share the workspace, table, column name, and timestamps so we can review accurately.
To avoid large, unexpected credit spend going forward:
Disable auto-run on expensive columns and run them manually
Use run conditions so columns only fire when inputs are complete
Test new enrichments on a small batch first
Avoid chaining auto-run columns unless necessary
These two docs go deeper on this:
https://docs.clay.com/en/articles/9642165-auto-update-and-auto-dedupe-table
http://www.clay.com/university/lesson/clay-credit-conservation
Let me know if you have more questions.
Ignacio J.
·
·
Thanks — that clarifies both auto-run spend and why Stop can appear to keep running. We’ll open a ticket now with workspace/table/column + timestamps for the incident review. Quick question: is there any way (or workaround) to add guardrails like a spend cap / confirmation prompt before an auto-run column dispatches at scale? We’re scaling high-volume workflows and want no surprises — happy to follow any recommended best-practice pattern for batching + run conditions to avoid accidental retriggers.
Andrew Q.
·
·
Hey Ignacio! As of right now, we do offer a few workbook level credit limits but it's available only on Enterprise plans. Our team are working to produce a few more features that will help with credit spend on the roadmap. As of now I would follow this framework to prevent credit burn:
Auto-Update controls - Turn off when not needed to prevent automatic refreshes
10-row testing - Test enrichments on 10 rows before running full tables
Run empty/error rows only - Avoid overriding existing data points
Sandbox mode - Build workflows without spending credits before going live
Clay Support
APP
·
·
We haven't heard back from you here, so we're going to go ahead and close this thread out.

Still need help here? Reply back and someone will jump back in.

Have a question thats not related to this thread? We recommend kicking off a new ticket in the support channel!