Handling automation throttling in Tape

[Tim]

Introduction

Automation throttling in Tape is not an issue - it’s a feature by design.
It protects system stability and ensures fairness across all customers.

Unlike some other platforms, where a single heavy user can cause a “bad neighbor” effect and slow down the entire platform, Tape ensures fairness with smart throttling and concurrency limits. This way, every organization gets reliable, consistent, and predictable automation performance.

Thanks to the flexibility and power of Tape’s automations, organizations can run even the most complex workflows at scale and there are also many reasons why automations may be throttled. Tape has customers with thousands of different automations and hundreds of thousands of runs per day. Without throttling, a single organization could overload itself or even come to a complete halt.

Throttling is good for all of us and at Tape we’ve made it transparent so each organization can improve its own setup. In most cases, automations are configured by world-class experts. But if not, only the individual organization is throttled, not everyone else.

For the benefit of all Tape users, we’ve designed Tape to be organization-centric, similar to platforms like Salesforce. This architecture makes it possible to allocate dedicated resources per organization. Even a single-license customer can run extremely heavy use cases, while enterprise organizations can scale far beyond.

With this guide, we’d like to share more details on how throttling works and what you can do if you don’t want to be throttled.

How throttling works

• Scope: applied organization-wide, not per automation.
• Mechanic: a fixed number of automation runs are always processed in parallel (Concurrency control).
  • If more are triggered → they go into the queue.
  • If the queue grows too large and too fast (calculated by score) → the organization gets throttled. Throttling is the escalation of queued automation runs.
• Effect: automations do not fail. They continue running, but at a slower pace.
• How the throttling score is calculated:
  • The score is calculated in real time, with a dynamic model that adapts automatically.
  • The algorithm combines both the time window and the type of automation runs.
    • The speed of queue growth is measured in time intervals.
    • Every consumed action adds to the scoring model. Complex code actions count more heavily than lightweight actions (e.g., comments).
  • If the score is exceeded, throttling is applied and runs show the status “Throttled.”
• Note: in very rare cases, runs may be rejected completely. For example, a Tape user once queued over 1 million runs at the same time on a premium plan leading to termination of runs.
• Benefit: throttling automatically prevents overloads within your organization.

Common causes of throttling

• Bulk updates - running flows on thousands of records at once (e.g., via imports, API usage, or webhooks), often involving external platforms.
• “Record update Any field” triggers - include calculated fields, generating many filtering runs
• Filter checks - background filter jobs (invisible in run logs) that consume throughput
• Cascading automations - updates that trigger further updates recursively
• Excessive code actions - heavy custom scripts or code blocks that consume significant runtime
• Search across many records - queries across large amounts of records in an app
• Imports - can trigger multiple automations at once, either directly during the import or through dependent triggers

Troubleshooting throttling

• If throttled: do nothing. Automation runs will catch up automatically. Runs are never dropped, only delayed.
• If you accidentally caused throttling: Pause or cancel runs. The system will recover on its own after some time.
• For anything else: Check why your organization is throttled. Helpful indicators include:
  • Common causes - review the most frequent reasons for throttling (see above).
  • Automation Center monitoring:
    • Home: see how many automations are active and how many are scheduled.
    • Runs: view details about runs and use filters to gain deeper insights.
    • Review changes made recently to your existing automations, or recently added ones. They may have introduced excessive load leading to queueing and/or throttling.
• Note: Tape does not review customer automations or code. For this, you can engage certified Tape consulting partners who have years of experience. Find the right partner here: Tape Partner Directory

What can you do if you don’t want to be throttled?

A) Community-proven practices to avoid throttling

Batch updates

• Process in smaller groups (200–400 records per run).
• Use scheduled automations (e.g., every 15 minutes).
• Always bulkify updates instead of looping through single records.
• Batch patterns like tape.Record.batchUpdate → example powered by Jason Melotte.

Dedicated trigger config

• Use a specific trigger configuration instead of “Any field.”
• This reduces hidden filtering jobs and speeds up processing.
• Avoid recursion so automations don’t trigger themselves repeatedly.

Optimize flow design

• Keep flows simple and short.
• Avoid unnecessary parallel HTTP calls or heavy code actions.
• Add error-handling paths so runs can retry gracefully if delayed.
• Avoid over-using delay actions in flows. While they technically do not produce load, they will still occupy a concurrency slot in your organization and delay other runs.

Don’t process imports at the time of import

Flag the new record as needing processing and then batch process over time. This way you allow breaks for the user-based automations to run. Make the flag user visible so that they are aware. Process the batches e.g. by periodically running an automation that collects the pending records that need processing. Credit to Jason Melotte

Revisit all ‘processing automations’

Can they be made into fewer, reducing the chain? Can the blocks/steps be reduced? Can some or all of it be scripted? Credit to Jason Melotte

Replace loops or conditionals where possible

If you use loops or conditionals, consider removing them and handling logic in a different way. Quite a few examples exist of using JSONata instead of loops. Credit to Jason Melotte

Testing new automations

Run a manual test with a single record first, instead of running the automation on a large number of records. After verifying that things work as expected, run on a larger badge and then run for your entire set.

Plan large operations

• Run flows overnight or in intervals.
• Stagger execution for bulk jobs.
• Control concurrency to avoid too many automations running in parallel at once.

Partner practices

Many of Tape’s partners handle heavy updates for their customers during off-peak hours. This isn’t because the software is slow, but rather because it’s standard practice to avoid slowing down productive users.

• User activity can also trigger automations → adding more load.
• Off-peak execution avoids conflicts with productive hours.

Use the API for data workloads

• For migrations or transformations → prefer the Tape API.
• Reduces automation bottlenecks and scoring load.
• Queue heavy jobs via API where possible for safer processing.

Update only record value differences

Update only the changed values within a record, rather than overwriting all field values, creating new records, or duplicating and then deleting them.

Automation priority

Automations are always processed in the order they start. There is no way to prioritize “user-triggered” vs. “bulk” or manual levels. This step-by-step processing ensures dependencies remain intact and results consistent.
If the system prioritized mid-process (e.g., moving user-triggered runs ahead), dependencies could break and results become unreliable. Instead, use smaller batch updates with pauses in between. This gives user-triggered automations time to run before the next batch starts.

B) Additional solution: increase throughput

To meet maximum organizational requirements, Tape offers the ability to allocate dedicated resources to significantly boost automation throughput.

• How it works: Additional servers are purchased and allocated to your organization.
• Impact: More automations are processed in parallel, queues drain faster.
• Cost: Based on Tape’s server costs
• Notes:
  • Throttling will still exist.
  • With higher throughput capacity, runs are processed faster and queues grow more slowly, as runs are worked off more quickly in parallel.
  • This setup can be scaled further by adding more servers, each one speeding up processing.
  • With this system, even a single-license organization can handle heavy data workloads, while enterprise customers with more than 5,000 users have already scaled on Tape and continue to grow.

Key takeaway, the strength of Tape compared to other providers is:

• Runs are never dropped, only delayed
• Throttling is organization-centric, with no impact on other organizations using Tape
• Fully transparent and visible to every admin
• Tape can be scaled with dedicated resources if needed

Result:

Throttling is the natural escalation of queued automation runs. It protects stability, ensures fairness, and benefits everyone. For additional best practices, which are virtually endless, we’d love to hear from you in the comments. Your input helps us create evergreen content for the community.