Workflow Limits And Troubleshooting

Workflow Limits and Troubleshooting

Workflows are powerful, but Tadabase enforces a few limits to keep your app safe — both from runaway loops and from unexpected costs. This article explains the limits, the guardrails Tadabase puts in place, and how to debug the most common problems.

Plan-based limits

Your subscription plan controls a few workflow capabilities. The exact numbers depend on your plan — check the Plans page or your Account Settings for the values that apply to you.

Limit	What it controls
Total workflows per app	Maximum number of workflows you can create in a single app.
Workflow runs per month	How many workflow runs are included in your plan.
Schedule frequency	The lowest scheduling interval allowed (e.g. some plans don't allow "Every Minute").
Workflow versioning	Whether you can save and restore versions.
Email volume	Total emails per month (Send Email steps count toward this).
SMS volume	Per-message SMS billing (Send Text steps).

Built-in safety guardrails

Even within plan limits, Tadabase has a few hard guardrails to protect your data:

Guardrail	What happens
Maximum steps per workflow	Workflows can't grow beyond a configured maximum number of steps.
Maximum chain depth	If Workflow A triggers Workflow B which triggers Workflow C — the chain is capped to prevent runaway loops.
Maximum execution time (soft)	If the workflow takes too long, you'll see a warning in History.
Maximum execution time (hard)	If the workflow exceeds the hard cap, it's terminated mid-run and marked as failed.
Custom Code timeout	JavaScript steps are capped at 30 seconds wall-clock and 128 MB memory.
Custom Code outbound HTTP	Only allowlisted hosts; private IPs are blocked.

When a guardrail trips, the workflow shows up in History with a clear error code and a description of what happened. The most common one is the "max chain depth" message — it almost always means a workflow is triggering itself indirectly.

Common problems and fixes

"My workflow isn't running."

1. Confirm the workflow is Active.
2. Confirm the trigger matches what you're testing — a Record Created workflow won't fire on edits.
3. Check the trigger filters — they may be excluding your test record.
4. Check the Queue and Running views in case the run is pending.
5. Confirm your plan allows the trigger frequency (e.g. "Every Minute" requires a higher tier).

"My workflow ran way more times than expected."

1. You probably have a self-triggering chain. A Record Updated workflow that updates the same record will trigger itself.
2. Add a trigger filter or Condition step so the workflow only runs when the field actually needs to change.
3. Or, in the action that updates the record, only update fields that don't satisfy the trigger filter.
4. If you got a "max chain depth" error, that's the guardrail catching it — fix the trigger logic to stop the loop.

"All my steps got skipped."

You almost certainly have a Condition step earlier in the flow whose conditions evaluated to false. Open the run in History and look at the Condition step — its log shows the evaluated values so you can see why it didn't match.

"A field I'm reading is empty when it shouldn't be."

1. Check the field slug, not the display name. Two fields can share a name but have different slugs.
2. Confirm the field is on the source record's table, not a connected table — connected fields need Connected Value, not Source Record Value.
3. For Record Updated workflows, confirm the field had a value before the update — workflows see the post-update record, not the pre-update one.

"My email/text didn't send."

1. Open the run in History and check the Send Email step's error message.
2. Confirm the recipient field is populated.
3. Confirm you haven't hit your monthly email/SMS quota.
4. For SMS, confirm the phone number includes the country code (e.g. +1 for US).
5. For email, check spam folders — sometimes messages are sent successfully but filtered.

"My integration step is failing with an auth error."

1. The token may have been revoked on the third-party side.
2. Open Manage Integrations and re-authenticate the connector.
3. Verify the connected account still has access to the resource you're trying to use (e.g. the Slack channel still exists).

"My Custom Code step times out or errors."

1. The 30-second wall clock applies to the entire script, including fetch calls. Long external calls can exhaust it.
2. If you see "Host not allowlisted," ask the workspace admin to add the domain to the allowlist.
3. Check the run logs (your console.log output) for clues.
4. For long-running work, move it to a Pipe or break it into smaller scheduled batches.

"My webhook step is failing."

1. Confirm the URL is HTTPS and reachable from the public internet.
2. Confirm the receiving service returns a 2xx HTTP status.
3. The step records the response status and body in the run logs — start there.

When to contact support

If you've checked the History, confirmed the trigger and inputs look right, and you still can't explain the behavior, file a support ticket with:

1. The workflow name and the app it's in.
2. A specific run timestamp from the History view (so support can find the same run quickly).
3. What you expected to happen vs. what actually happened.
4. Any error message from the run logs.

Best practices to avoid problems

• Name everything well. Clear workflow names, clear step names, clear branch names. You'll thank yourself later.
• Always Dry Run before activating a workflow that updates data or sends messages.
• Use trigger filters liberally — let the workflow stay quiet most of the time and only run when needed.
• Save versions with comments so you can roll back if a change goes wrong.
• Keep secrets in App Variables, not in step config or Custom Code.
• Watch the History view after every meaningful change. Catching a problem on the first run is much cheaper than catching it after thousands of bad runs.