Notion Workers sync: what it can and cannot do

Notion Workers are small TypeScript programs that Notion hosts and runs for you. One of the things they do is sync, which pulls data from an outside service into a Notion database on a schedule.

That sync runs one way, into Notion. Every column it owns becomes read-only, so you cannot change a task's title or its due date from the Notion side. Workers also require a Business or Enterprise plan, and from 15 October 2026 they bill per run through Notion credits.

What are Notion Workers?

A worker is a single TypeScript file you write, deploy with Notion's ntn command line tool, and Notion runs on its own infrastructure. You never provision a server.

Each worker registers capabilities. There are three: syncs that pull external records into a Notion database on a schedule, tools that Notion's Custom Agents can call, and webhooks that catch events from other services. Only the first of those is a sync in the sense most people mean.

Notion draws the line itself in its help center. Automations are built into Notion and designed for anyone to set up, while Workers are for developers who want to run custom code. Notion ships Workers as a beta feature, with webhooks a step further back at alpha.

Notion Workers and 2sync at a glance

With Workers, synced columns are read-only in Notion

This is the constraint that decides most workflows. Notion's sync documentation states it plainly for a Worker sync: synced columns are read-only, and you cannot manually edit any property declared in the sync's schema. Row titles and icons are locked the same way, and rows cannot be added or deleted by hand. Only the sync writes them.

Columns you add outside the schema stay editable, so you can keep your own status field next to the synced data. The synced fields themselves are not yours to touch.

Picture a Todoist worker. It pulls your tasks into Notion beautifully. Then you open Notion, try to push a due date back a day, and Notion will not let you. To change it you go to Todoist, change it there, and wait for the next run.

For a dashboard nobody edits, that is correct behavior and a genuine feature. It guarantees Notion matches the source. For a workflow where Notion is where you actually work, it removes the reason you connected the two apps.

The sync API has no two-way option at all. Notion's answer for pushing changes outward is a second, separate worker built on the webhook capability, triggered by a Notion automation. You write that reverse path yourself, and with it the loop prevention, the conflict rules, and the delete detection.

Who can use Workers, and what they cost

Workers are available on Business and Enterprise plans. Notion Business is $20 per member per month. A workspace on Free or Plus cannot use Workers at all, whatever its members can code.

By default the feature is switched on for owners only, so on a team workspace an admin has to grant access before anyone deploys anything.

Billing is the part worth doing arithmetic on. Notion's free beta covers Worker runs through 14 October 2026. From 15 October 2026 they consume Notion credits, which cost $0.01 each, and Notion prices a worker run at roughly $0.0023. Each time a scheduled sync runs, that counts as one run.

The fastest schedule a sync can take is every 5 minutes. At that cadence one sync fires 8,640 times in a 30-day month.

Sources: Notion Workers pricing and Notion pricing, both verified 15 September 2026. 2sync figures from our pricing page.

The method here is Notion's own. Its published example puts a 15-minute Salesforce sync at 2,880 runs and $6.62 a month, and the same arithmetic produces the figures above.

Two caveats, both pointing the same way. Notion says the credits per run vary with how much work a worker does, so $0.0023 is a floor rather than a ceiling. And Notion's troubleshooting advice, when a bill looks wrong, is to lower the run frequency. Cost and freshness pull against each other by design.

The per-run price also hides what you are actually paying for. A run bills whether or not anything changed upstream. A calendar that picks up three new events a week still fires 8,640 syncs a month on the 5-minute schedule, and every one of them is billable. The meter follows the polling, not the work, which is why a quiet database and a busy one cost exactly the same.

One more thing the table cannot show: Workers cannot run faster than every 5 minutes. The 3-minute and 2-minute cadences on our Premium and Pro plans are not available at any price, and the default schedule for a new sync is every 30 minutes.

You bring your own Google or Microsoft app

Workers do not handle provider sign-in for you. For an API that needs user authorization, Notion's documentation sends you to register an OAuth capability and supply your own credentials. For Google Calendar, Gmail, or Google Tasks, that means your own Google Cloud project and your own OAuth app.

Google's rules then apply to you rather than to Notion, and they are strict.

• An unverified app is capped at 100 users, for life. Google's cap covers the entire lifetime of the project and cannot be reset or changed. Your users see an unverified app warning on the way in.
• Test mode expires tokens every seven days. A project left in Testing is limited to 100 test users, and authorizations expire seven days after consent, refresh tokens included. A sync built this way stops working every week.
• Gmail needs an annual security assessment. Every Gmail scope, gmail.readonly included, is classified restricted. Any app that reads restricted data through a server must pass a security assessment under the CASA framework, and repeat it at least every 12 months. Verification alone can take several weeks.

We carry those apps so our users do not have to. 2sync runs the verified Google and Microsoft applications, and requests the narrow scopes listed on our security page, which is why connecting Gmail or Google Calendar is a sign-in rather than a project.

For a consultant setting this up for clients, the difference is stark. One path ends after a hundred client accounts and needs an annual audit. The other is a button.

Pointing a worker at a database you already use

A sync can attach to a database you already have, using an attached declaration bound through the command line. Notion's warning on that page deserves quoting: attaching hands your worker control of the real database, including its rows, and the sync may overwrite or delete existing rows, resulting in data loss.

There is a second trap further down. Deleting the worker, or removing the database declaration from your code and redeploying, does not release the database. It stays locked and orphaned, and the fix is a detach command you have to know to run first.

Replace mode has a quirk of its own. It deletes any row it did not see during a cycle, so a sync that errors halfway through deletes nothing, by design, and your database holds stale rows until the next clean run.

None of this is hidden. It is written down clearly, which is to Notion's credit. It is also a set of failure modes the person who deployed the worker now owns.

2sync never takes a database over. It writes only the properties you map, leaves every other column alone, and you can still add, edit and delete rows in Notion yourself.

What you would build and maintain yourself

A worker gives you a runtime and a schedule. The rest of what a sync tool does is yours to write.

• Rate limiting. Notion supplies a pacer you configure yourself, for example ten requests per second, and you decide the numbers for every API you touch. Get them wrong and the provider throttles you. Our retry handling uses exponential backoff and dynamic batch sizes across Notion, Google, Microsoft and Todoist, and nobody configures it.
• Conflict rules. When the same record changes on both sides between runs, something has to decide what wins. We resolve conflicts per field rather than per item, so a title changed in Notion and a date changed in Google Calendar both survive.
• Delete detection. Deciding that a missing record means delete rather than a failed fetch is the difference between a tidy database and an empty one. Our safety limits halt a sync before it removes more than half the synced items, and again before it creates duplicates.
• Workspace run limits. Notion caps sync runs at 600 per hour across the whole workspace, shared by every worker in it. Ten syncs on the 5-minute schedule use 120 of those every hour, so a busy workspace has a ceiling to plan around.

None of that is exotic. It is simply what a sync engine does once someone else has written it. Then there is the ordinary maintenance that any integration carries. Provider APIs change, schemas drift, and adding one field to a synced database means editing the schema block, editing the mapping, redeploying, resetting sync state, and triggering a re-run.

When a Worker is the right tool

Workers are genuinely good at a job no sync service covers. It is worth naming that job exactly.

If you are on Business, you write TypeScript, and you want a read-only mirror of Salesforce, Zendesk, Stripe, Jira, or an internal database inside Notion, a Worker is built for exactly that. Nothing has to leave Notion's infrastructure, the read-only lock guarantees the mirror matches the source, and an agent can read the result. The same is true for anything with a JSON API that no vendor has built a connector for.

Reach is what you are buying. A Worker can sync anything you can code against, which is a far wider set of systems than any sync product supports. If the systems you had in mind are databases rather than calendars and tasks, that is a different category from ours, and how we compare with Whalesync covers where each of us fits.

What it does not cover is the case where a person edits the same record in both places. That is a different problem, and a read-only column cannot solve it. Ticking a task off in Notion and expecting Google Tasks to agree is the everyday version of it.

How 2sync covers the same ground

2sync connects Notion two ways with Google Calendar, Todoist, Google Tasks, Outlook Calendar, Gmail, Outlook Mail, Google Contacts and Outlook Contacts. Changes flow in both directions on their own, and your Notion properties stay editable throughout.

Direction is set per field, not per automation, so one record can hold two-way fields next to fields that only ever flow one way. An organizer or a created date can stay locked to the provider while the title and the date stay editable in Notion.

That choice matters more than it sounds. Nearly 79% of our active users run two-way only, and they work from whichever app is open at the time. A read-only mirror would not serve any of them.

Anyone who can build a Notion database can set one up. Setup is a browser flow and takes about five minutes: connect the provider, pick the Notion database, map the properties, set filters if you want them. Nothing is installed and nothing is deployed, so there is no code to maintain when an API changes. Across 127,000 accounts in 202 countries we have processed more than 2.5 million synced items.

Pricing is per account rather than per member, and every plan carries every integration. If you want the specifics of how direction behaves before you set anything up, two-way and one-way sync covers it.

Which one fits your workflow

Work backwards from where the editing happens.

• You only read the data in Notion, and it comes from a system nobody else connects to. Build a Worker, if you are on Business and someone writes TypeScript.
• You edit in both apps. Use a two-way sync tool. A Worker cannot write your Notion edits back, whatever else you add around it. 2sync writes changes in both directions, field by field.
• You are on Free or Plus. Workers are not available to you at all. 2sync works on any Notion plan, Free included.
• You want a one-time action rather than continuous matching, like posting to Slack when a row changes. That is an automation platform, and Zapier alternatives for Notion compares the realistic options, with 2sync against Zapier side by side.
• You want calendar, tasks and email in Notion without writing anything. Start with Google Calendar, Outlook Calendar, Todoist or Gmail.

The two approaches also coexist fine. A Worker mirroring your CRM and 2sync syncing your calendar solve different problems in the same workspace.

Conclusion

Notion Workers are a developer feature, and Notion says so. They extend Notion's reach to any API you can write code against, and they do it without a server.

What they do not do is two-way sync. The columns a Worker syncs are read-only, the sync writes into Notion and never out of it, and the workaround is a second worker you build and maintain. Add the Business plan requirement, the credits that apply from 15 October 2026, and your own OAuth app with Google's caps attached, and the honest picture is a powerful tool aimed at a narrow job.

If your data only needs to be read in Notion, that job might be yours. If you work in both apps, you need the edits to travel in both directions.

FAQ