monday.com automations: what to keep native, how actions are counted, and when to move to Make

An automation is a rule attached to one board. It has a trigger (a status changes, a date arrives, an item is created), optional conditions (and only if the priority is High) and one or more actions (notify someone, set a date, move the item, create an item on another board). An integration is the same recipe with an outside tool on one side: send an email through Gmail or Outlook, post to Slack, send a webhook when a column changes. Both are set up from the board's Automations page and live on that board, though either can act on another board.

The difference that matters day to day is which allowance pays. monday keeps two monthly action limits, one for automations and one for integrations, and its Help Center is specific about which bucket each kind of recipe draws from. It is not always the bucket the name suggests.

Two points follow. First, a Make or n8n scenario that reads and writes monday through the API does not spend monday actions for its own calls; it spends Make credits or n8n executions, plus monday API calls. Second, it can still spend monday actions indirectly, by changing a column that a recipe is watching. That second point is how a quiet integration ends up consuming a busy board's quota.

monday counts actions executed, not recipes and not runs. Its Help Center says most templates use one action each time they are triggered, then lists the exceptions, and the exceptions are where quotas go.

• Creating an item. One action for the item, plus one for each Status, Tag, People or Dropdown column, or Update section, that the recipe maps into it. monday's own example, create an item with two Status columns mapped, uses three actions a run.
• Notifying a team or the board's subscribers. One action per notification sent, so a board with six subscribers uses six actions every time the recipe fires.
• Emailing through Gmail or Outlook. An email to a text column holding several addresses, a team or the subscribers uses several actions. monday itself advises that these integrations can consume a lot of actions.
• Recurring recipes. Every time period, create an item uses an action on each run, plus the mapped columns, whether or not anyone needed the item that day.
• Workflows. Condition steps in the workflow builder consume actions when they execute, not only the steps that change something.
• Bulk edits. A recipe triggers once per affected item. Changing the status of two hundred items in one batch action runs a status recipe two hundred times.

The allowance, the reset and what happens when it runs out

The limits depend on the plan. On 21 October 2026 monday's Help Center listed 250 automation actions and 250 integration actions a month on Standard, 25,000 of each on Pro and 250,000 of each on Enterprise; check monday's pricing page for the figures that apply to your account today. The allowance resets at the start of each monthly billing cycle. Admins are emailed at 50%, 75% and 100% of it. Administration, then Usage stats, shows the top consuming automations, boards and creators, and the Usage tab in the Autopilot hub lists every source of consumption, including apps.

Running out is worse than it sounds. monday deducts overuse from the following month's allowance, and once the current month's actions are gone the account is blocked from editing or adding automations and integrations. monday's documentation notes that heavy overuse can consume next month's allowance as well, so an account can start a month with nothing available. Separately, there are per-minute rate limits per automation, per board and per account. Past the lower threshold runs slow down; past the higher one new runs fail, which raises the automation's error rate and can lead to it being switched off. Loops, API or webhook traffic and batch actions are the causes monday names.

The good recipes share a shape: one trigger that means one thing, one or two actions, and nothing that needs data from outside the board. These are the ones we keep native on operations and CRM boards, and what to watch on each.

The last row is the bridge to everything else. A Webhooks recipe lets the board decide which events matter, so Make or a service is woken only for qualifying items rather than for every edit. Our monday.com and Make integration guide treats that as one of three ways for Make to hear about a change, and our article on monday.com webhooks created by an app explains why a recipe like this keeps posting after the scenario behind it has been deleted. monday's documentation does not say whether each webhook delivery counts as an integration action, so watch the Usage tab for a week after you add one.

The filter matters as much as the trigger. On a pipeline board we automated in Make, a document chase fires when a lead moves into a Document Follow Up group from one specific group. It has 17 runs and 21 operations in Make's counters with no errors, and most runs stop at the first filter because the move was between other groups. A native recipe with a precise trigger does the same job for free in Make terms, but it still spends a monday action every time it fires, so the narrower the trigger, the cheaper the board.

When a recipe stops firing, or fires when it should not, the cause is usually structural rather than a bug. These are the failure modes we see most often, roughly in order of how much damage they do.

A status column that means three things

It starts as the stage, gains a couple of outcome labels (Lost, Won), then picks up Blocked and On hold. Now a recipe bound to Won cannot tell a deal that has just closed from one someone re-labelled while tidying, and nothing can tell what is actually in flight. The fix is three columns for three questions: stage, outcome and blocker, each with its own small label set, and recipes bound to the one column that answers their question. In our experience renaming a label or rebuilding a column can also change or break the recipes bound to it, and a recipe whose column was deleted is deactivated, so fix the label set early and treat it as an interface.

Recipes that trigger each other

One automation's action can be another's trigger. monday's own example is the Outlook integration: an email sent by a recipe creates an update on the item, and a recipe that sends an email when an update is created then fires again, indefinitely. Cross-board pairs do the same (board A creates on B, B updates A), and so does a Make scenario that writes a status a recipe is watching. Loops burn actions, hit the per-minute rate limits and end with the recipe failing or being switched off. To stop one, turn the recipe off from the board's Automations page, under Manage. To prevent one, give each column a single rule that owns it, and never let a recipe write to a column that its own trigger, or a scenario's, is watching.

Actions burned by bulk edits

Batch actions run a recipe once per item. Re-labelling a few hundred items, importing a backlog into a status, or moving a group in one go can spend a month's Standard allowance in a minute and trip the rate limits at the same time. Before a clean-up, switch off the recipes that watch the column you are about to change, make the change, and switch them back on.

Recipes owned by someone who left

Every automation has an owner, and when that user is deactivated their automations and integrations are deactivated with them. Some deactivations send no notification, so the first sign is work that silently stopped happening. An admin can transfer all of one person's automations under Administration, then Directory, then Automations ownership, but the user has to be reactivated first. A single automation can be transferred from its menu on the board's Automations page. The cheap prevention is the default owner setting, which moves a deactivated user's automations, integrations and workflows to a named active user automatically. Recipes are also deactivated when their owner loses access: unsubscribed from a board with permissions, denied a column the recipe uses, or changed to a viewer.

Everything else

For a failed run, the notification links to that automation's run history, where the failed run expands into a reason. The Autopilot hub's Health tab shows which automations across the account are running and which are failing. If you have to raise it with monday, the automations activity log gives a trigger ID for the exact run.

Keep the rule native while its whole life is on the board: one trigger, a condition or two, actions that change this board or a linked one, and nobody needs to know why it did nothing. Hand off as soon as the rule needs something a recipe cannot hold. These are the tests we use.

Invoicing is the clearest example of the second and third rows. In a Make build in our library, a monday.com status change raises a Xero invoice: the scenario finds the contact, creating it if missing, creates the invoice due in seven days, emails it through Xero and writes the invoice number, date and link back onto the item. Across its six scenarios, Make has counted 78 runs and 782 operations with one error. No native recipe can do the contact lookup and fallback, and the build's own limit makes the third row's point: creating an invoice is not idempotent, so setting the trigger label again raises a second invoice. A status trigger fires every time an item changes to that label, including by mistake or during a tidy-up. Anything that creates money or messages needs a guard that a recipe cannot provide.

We have built the same pairing in Zapier, taking WordPress and WooCommerce orders into monday.com and then into Xero invoices with several line items. Whichever tool carries it, the shape is the one above: the board owns the state of the work, monday's recipes handle what happens on the board, and the integration platform handles what happens in other systems.

The last rows are where integration platforms run out too. The fleet-order build in our work needed a two-business-day clock against a real public holiday calendar, escalation that survives a job being reallocated, and installers updating their own jobs without seats. None of that is a recipe or a scenario. A small service owns the monday token and every board write, and the board stays the place people work. Our monday.com page covers that architecture, and our Make.com credits article puts numbers on the cost of moving work into scenarios.

1. 01Decide what an item is and give each status column one meaning before writing any recipe. Recipes bind to labels, so the label set is an interface.
2. 02Set a default automation owner, or build recipes from a shared admin user, so nobody's departure switches them off.
3. 03Give each column one recipe that writes to it, and name recipes in their description so the board says what fires on it.
4. 04Count actions per run for each recipe, multiply by a realistic month, add one bulk edit, and compare it with your plan's allowance on monday's pricing page.
5. 05Before any batch edit or import, switch off the recipes that watch the columns you are changing.
6. 06For every Webhooks recipe, record where it points and what listens to it, and delete it when that listener goes.
7. 07Check the Usage tab and the Autopilot hub's Health tab after the first week, then monthly.

Where it breaks: a checklist cannot stop a board from becoming a database. If the questions people ask need numbers aggregated across linked boards, more recipes will not answer them, and our comparison of Airtable and monday.com explains when the core object has outgrown a work platform.

A disclosure. Skofi is paid to design monday.com boards and automations and to build the integrations around them, including Make, Zapier and code that connects monday.com to accounting systems; Divine Kitchens, whose review is on our site, is one client running monday.com alongside Xero. We are not a monday.com partner and hold no certification or reseller arrangement with monday.com, Make, Zapier, n8n or Xero.