How are executions counted across multiple instances (ST / SIT / PROD)? Advice on keeping execution volume under control

Questions
1

Describe the problem/error/question

Hi everyone,

Sorry I am new to n8n and need guidance to handle a project inside my team work.

We’re moving our n8n setup to a three-environment model and want to make sure we understand how executions are counted before we agree on a licence quota with n8n.
Our setup

  • 3 self-hosted instances: ST (dev/build), SIT (integration testing) and PROD
  • Promotion through Git: ST → SIT → PROD via merge requests (source control / environments feature)
  • ~185 workflows in scope after cleanup (out of ~270 today). Many of them are schedule-triggered, and a large group of them call each other as sub-workflows.
  • Our licence quota applies to all instances combined
    Current numbers (approx., per month)
  • PROD: ~20–30k executions
  • ST: ~28k executions. Almost all of them come from scheduled workflows that stay active 24/7, even on weekends.
  • SIT: very low (a few hundred)
    So our non-production instance currently uses more executions than production, which seems wrong.
    Questions on how executions are counted
  1. Which executions count towards the quota? Is it only production executions (active workflows started by a trigger), or do manual runs from the editor count as well?
  2. Do sub-workflow calls (Execute Workflow node) count as separate executions?
  3. Do failed executions, retries and error workflows count?
  4. With a quota shared across instances, is the count aggregated per licence key? Is there a recommended way to monitor usage per instance before reaching the limit?
    Questions on environments and execution volume
  5. How do you handle schedule triggers in non-prod instances? Do you keep workflows inactive by default in ST/SIT and only activate them while testing? Or do you have a way to deactivate triggers automatically when you pull from Git?
  6. Any best practices to reduce execution volume without losing functionality? For example:
    • replacing polling schedules with webhooks
    • lowering schedule frequency
    • merging sub-workflows
    • filtering early so runs don’t happen for nothing
  7. How do you size the licence quota when you have several environments? Do you set a budget per environment?
  8. Do you set up alerts on daily execution counts? We had a spike of around 6k executions per day for two months that we only noticed afterwards.
    Any experience, patterns or pointers to documentation would be much appreciated. Thanks!

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 2.41.7 - Business Edition
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Hey @akurt, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@sergeys, @hideto, @achamm - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Only production executions count towards your quota. These are executions started automatically by a trigger (Schedule, Webhook, Polling, etc.) and are running in the background. Manual runs (clicking “Execute Workflow” in the editor) do not count toward your license quota.

No

Since version 2.28.0 (for self-hosted Business/Enterprise), runs of error workflows are excluded from your execution quota. If a workflow fails and triggers its designated error workflow, only the original failure counts; the error workflow’s run is free.

Failed Executions: If a scheduled workflow triggers and then fails, it still counts as an execution.

Retries: If you use the built-in “Retry on Fail” setting on a node, it is considered part of the same execution and does not count as a new execution. However, if you have a mechanism that triggers a new workflow run upon failure (rather than using the Error Workflow feature), that would count as a new execution.

Yes, for n8n Business and Enterprise licenses, the execution quota is aggregated across all instances associated with that license key.

You should use the Insights feature. Insights are recorded separately from the standard execution history, meaning even if you prune your execution data to save disk space, your usage metrics remain intact.

Insights allow you to see usage broken down by project or workflow. Since you likely have different projects or instances, you can use these metrics to identify which environment (ST, SIT, or PROD) is consuming the most volume.

n8n does not have a built-in “Email me when I hit 80% quota” button in the UI, but since you are self-hosting, you can monitor the usage via the n8n API or by querying your database (if you use the Insights tables/metadata) to build your own alerting system.

Replacing a “Poll every 1 minute” schedule with a Webhook is the single most effective way to drop execution counts.

To avoid the “6k executions per day” surprise, I recommend creating a simple “Watchdog” workflow in your PROD instance that queries the n8n API (or your database) once a day to check the execution_count for the last 24 hours and sends a Slack/Email alert if it exceeds a defined threshold.

4

akurt, with ST producing 28k runs a month, I’d start with the schedules that remain enabled outside actual testing.

One five-minute schedule means 288 starts a day, or 8,640 over 30 days. An IF that exits because there is no work can save downstream API calls, but the schedule has already started an execution. The quota docs⁠ distinguish that from a polling trigger returning no new data. I’d check which type each high-volume workflow actually uses before estimating savings.

For ST/SIT, I’d keep scheduled entry workflows unpublished by default. For each scheduled integration test, record which workflows must run, who owns the test and when they should be unpublished again. Keep that policy separate from your workflow code so promoting the same logic doesn’t mean keeping every environment’s schedules running. Use test credentials and retain any schedules genuinely needed for the test.

There’s a useful Git detail here: Auto publish Off⁠ means “keep the current local publish state”, not “unpublish everything I pull.” So it won’t switch off an already-published ST schedule. Verify that on your 2.41.7 setup before putting it into deployment automation.

For a first pass, take the busiest ST workflows from Insights and put their trigger type, interval and test end date in a small table. Calculate expected daily starts for the fixed-interval schedules and compare that with the actual runs over the same period. That will show which schedules are simply doing what they were configured to do and which need investigation. You can do this before building another monitoring workflow. Insights is useful for that comparison, but its raw total isn’t the licence meter: it also includes error-workflow runs.

Then size the shared quota from the corrected baseline, including planned test windows and known busy periods, rather than pricing in schedules nobody intended to leave running.

Could you share the trigger type and interval for your five busiest ST workflows, and which genuinely need to run outside test windows? Redacted names are fine.

5

Hi @akurt, one detail on retries: Retry on Fail stays within the original execution, but retrying a saved failed execution creates a separate billable run, even when you start that retry from the UI.

Business also includes a weekly usage email combining all instances using your licence key. For annual Business subscriptions, n8n contacts you near 80% of the annual quota:

For daily spike alerts, call GET /api/v1/insights/summary on each instance using an owner/admin API key, with startDate and endDate covering the same 24-hour window, then read total.value. Set separate ST/SIT/PROD thresholds and a combined threshold. As Marchik mentioned, Insights includes error-workflow runs, so these totals are useful for spotting spikes but can differ from billed usage.