Understand pricing for Workers (beta)

Workers run code in the background to automate tasks in Notion. They’re best for tasks that don’t require AI reasoning, such as syncing data, writing updates, and handling events. Workers are often paired with Custom Agents, where the agent decides what to do and Workers reliably execute specific steps.

During the beta, Workers are free to try on Business and Enterprise plans (including Business trials). Starting on August 11, 2026, they’ll require Notion credits. Workspace admins can purchase Notion credits as an add-on to Business and Enterprise plans.

The free beta period applies only to Workers. Custom Agent actions will consume credits according to your workspace’s plan and credit settings.

Workers use Notion credits, which are counted in runs. Each run represents one unit of work completed on your behalf. The number of credits per run can vary depending on how much work the Worker does, like how long it runs or how much processing it needs. In general, the more work involved, the more credits used.

Workers can run in a few different ways (we’ll keep expanding this list):

• Syncs (scheduled): Each time a sync runs counts as one run.

• Tool calls (agent-triggered): Each time a Custom Agent triggers a Worker tool call counts as one run.

• Webhooks (event-driven): Each event a Worker handles counts as one run.

Workers typically cost $0.0023 per run, which works out to ~4,348 runs per 1,000 monthly Notion credits ($10). They’re cheaper compared to Custom Agents because pricing is based on how much work they do when they run and they don’t require AI decision-making.

The tables below break down cost benchmarks for each type of Worker action. Use this as a starting point to understand costs. Your actual usage may vary, and is the best way to size credits.

The table below shows examples of usage. Your actual usage depends on how often your syncs run and how much a Worker does for each run.

Syncing more data or handling several updates will cost more. If you have multiple syncs, multiple Workers, or Workers that run in response to many events, total usage may be higher.

Workers can also power custom tools that Custom Agents use. For example, a Custom Agent might call a Worker to fetch data from another system, run a calculation, or update records.

Tool-call usage depends on how often an agent calls a Worker. Each tool call counts as its own Worker run (so one agent run can generate multiple Worker runs).

The table below shows typical webhook volumes and what they might cost. Your actual usage depends on how many events your tools send and how many webhook triggers you’ve set up. Each incoming event that you handle counts as one Worker run, so total cost scales with your event volume.

During the free beta, you can track Worker credit usage directly in the CLI, including the last seven days of usage. Worker usage will also appear in the Notion credits dashboard by the end of May, so admins can track credit usage for Workers and Custom Agents in one place.

You can manage Workers across your workspace by going to Settings, and selecting the Workers tab. From here, you can:

• Switch Workers on or off for your workspace. By default, Workers are turned off.

• Control who can use Workers, including specific people or user groups.

• Track and manage individual Workers.

  • View all Workers in your workspace, including their owner and status.

  • Disable or delete a Worker at any time.

  • Pause all Workers.

Workers are free during beta, so you can use this time to run real workflows and estimate how many credits you’ll need once credits apply.

Try these best practices to keep Worker usage predictable:

• Start with a slow schedule. For syncs, start with hourly or daily runs if real-time updates aren’t required.

• Increase frequency only when needed. Move to every 15 minutes, 5 minutes, or every minute only if the workflow requires it.

• Batch work when possible. Instead of running a Worker for every small change, group updates together.

• Sync only what you need. Sync only the databases, records, or fields that are needed.

• Avoid unnecessary retries. If a Worker fails, make sure it doesn’t retry too frequently without resolving the underlying issue.

• Review usage regularly. Check CLI usage during setup and after major workflow changes.