Syncing Notion with Google Calendar for free

Anyone searching for a free way to sync Notion with Google Calendar has usually already built the database. The dates are in there, the tasks are tagged, the view is set to calendar, and none of it shows up next to the meetings that actually govern the day. The obvious fix is a sync. The less obvious fact is that the word covers three different jobs, only one of which runs into a paywall.

Sorting those three apart takes about a minute and saves an afternoon of reading setup guides written for a problem nobody has. What follows is the shape of each option, what the free tiers actually cap, and the point where the free route costs more attention than a paid one costs money.

Three jobs hiding behind one word

Write down which of these describes the goal, in one line, before opening any settings page.

• Seeing Google Calendar events inside Notion, for context while writing
• Pushing dated Notion database rows out to Google Calendar so they appear on a phone or a shared calendar
• Editing in either place and having both stay correct

The first is free and takes minutes. The second is free within limits that are easy to stay under. Only the third collides with the caps on free automation plans, and it is also the one people ask for by reflex rather than by need.

Two way sync is genuinely necessary when more than one person edits the same item, or when the editing surface changes depending on where the person happens to be standing. It is not necessary when one person enters everything in one place. Deciding to always create in Notion, or always create in the calendar, removes the entire problem and costs nothing.

What the built in apps already do

Notion Calendar is free, runs natively on macOS, and connects Google accounts with full create and edit rights. It also connects Apple iCloud, which requires an app specific password issued by Apple, and Microsoft Outlook accounts. More usefully for this question, a Notion database can be layered directly into it.

Any database with a date property can be added to Notion Calendar. Source: notion.com

That single line resolves a large share of the searches that land on sync tutorials. Meetings and database rows appear in one window, on one time axis, at no cost. What it is not is a sync. The database layer is a view, and it lives inside that application. Those rows do not become Google Calendar events, so they are absent from a phone's default calendar app, absent from a shared team calendar, and invisible to anyone checking availability.

The test is simple. If every look at the schedule happens on the Mac, the job is finished here. If the schedule also needs to be legible on a phone lock screen or to a colleague booking a slot, the row has to become a real Google Calendar event, and that requires one of the routes below.

The read only tier: embeds and subscriptions

Going the other direction, a Google Calendar can be embedded inside a Notion page. Google publishes an embed address in the calendar settings, and pasting it into a Notion page produces a live view of the week alongside notes. It costs nothing and takes a couple of minutes. It is a window, not a connection: events created in that frame do not become database rows.

The reverse direction relies on an older and more portable idea, the iCalendar file format, which is what every subscribe by URL feature is really passing around.

This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. Source: rfc-editor.org

Subscriptions are read only by design, and the subscribing calendar decides how often to fetch. Google does not expose that interval as a setting, and a delay of several hours is normal. For deadlines that settle a day ahead, that is fine. For a meeting time that moves at eleven in the morning, it is useless.

Deciding what maps to what

Every route above, free or paid, has to answer the same question: which piece of a database row becomes which piece of a calendar event. Settling that before building anything prevents most of the cleanup that otherwise follows.

The date property is where the decisions concentrate. A Notion date property can be a bare day, it can carry a clock time once Include time is switched on, and it can hold a range once End date is switched on. Those three states produce three different results on a calendar. A bare day becomes an all day banner across the top of the grid. A time with no end becomes an event whose length is chosen by the sync rather than by the row. Only a range with times produces the block most people had in mind when they started. Switching on End date for the property being synced is often the single change that makes the resulting calendar readable.

Databases usually hold more than one date property, such as a created date, a due date, and a review date. A sync can follow only one of them, so name the chosen property explicitly and keep the others out of the configuration. Renaming that property later breaks the connection, which is worth knowing before a tidying session.

Time zones deserve a deliberate answer rather than a default. Notion exposes a date format and time zone setting on the property itself, while a Google Calendar event belongs to the time zone of the calendar holding it. Left unexamined, the two agree at home and disagree the week someone travels, and the symptom shows up as events landing hours off rather than as an error message.

Everything with no counterpart stays behind. Status, select values, relations, page content, and comments have nowhere to live on an event, so treat the calendar as a projection of two or three fields rather than a copy of the row. Point the sync at a calendar created for this purpose alone, and a bad first attempt can be undone by deleting that one calendar instead of hunting individual events.

Where the free automation tiers stop

Two way sync without code means an automation service. Both of the common ones have a free plan, and both cap it in a way that matters more than the feature list suggests.

Route	Free allowance	Fastest check	Realistic use
Zapier	100 tasks per month, two step workflows	15 minutes	One direction, creates only
Make	1,000 operations per month	15 minutes	One direction with conditions
Apps Script	Free within Google's own execution quotas	Set by the author	A fixed spec, maintained by hand

Translate the first row into days. At 100 tasks a month, and one task consumed per event created, the allowance covers roughly three new events a day. Two way sync needs two separate workflows, one in each direction, so consumption doubles before edits and deletions are handled at all. Adding those pushes a normal working schedule past the free ceiling somewhere in the third week.

The polling interval is the sharper constraint. A fifteen minute floor means a time changed just before a meeting reaches the other system up to fifteen minutes later, which is exactly the window in which the change mattered. Free automation suits a schedule that gets tidied once in the evening, not one that gets corrected while walking to the door. Anyone whose day looks like the second case should skip the free automation tier entirely rather than discover the lag during a bad week.

There is also a failure mode that no pricing page mentions. Two workflows pointed at each other will happily re create what the other just wrote unless something marks which side originated a record. Every serious guide handles this with an extra property in the database that stores the matching event id, and that property is the difference between a sync that runs quietly and one that produces duplicates every quarter hour.

Writing it yourself

Google Apps Script plus the Notion API costs nothing beyond time, and it removes the interval limit, since the trigger can run as often as needed. The trade is that a list of decisions moves from a vendor to a person:

• Storing and rotating the Notion integration token, and sharing the database with it
• Choosing which side wins when both changed since the last run
• Recording the event id on the row so nothing is created twice
• Deciding what a deletion means, in each direction
• Handling all day events, recurring events, and time zones
• Fixing it when either API changes

Most of the work sits in the third and fourth items. A version that creates events is an afternoon of work. A version that survives someone dragging a meeting to next week, then deleting it, is a different project. The honest summary is that this route is free of charge, not free of effort, and it needs about an hour of attention a month to stay trustworthy.

When paying starts to make sense

Several products exist purely to hold a Notion database and a Google Calendar in agreement. Pricing sits in the region of seven dollars a month when billed annually, and the free tiers that exist tend to cap how many events move per sync cycle, with fifty events per cycle being a common limit. Vendors change these numbers, so treat them as the starting point for a check rather than a settled fact.

The line for paying is narrow and easy to test. It is worth money when the schedule changes several times a day, or when more than one person edits the same items from different apps. Below that, the free tier is not a compromise, it is simply enough. Above it, the monthly fee is smaller than the time spent untangling duplicate events, and the comparison should be made in those terms rather than in features.

What a synced calendar still will not fix

Once the database rows land on the calendar, a different problem becomes visible: the day fills up far faster than expected. That is an accurate picture rather than a bug, and it is also incomplete, because nothing on that grid represents travel or the pause between one kind of work and another.

A day with two appointments in different places collapses regardless of how precisely the tasks were synced. Whether movement gets reserved as an event is a design decision, not a sync setting, and the effect of reserving the return trip and alerting on departure time instead of start time is covered in Travel time. Plenty of sync projects turn out to be attempts to fix a schedule that never had gaps in it.

The second thing worth checking is entry speed. The reason for building a sync is almost always to have one place to type into. If that is the goal, then how fast that one place accepts a half formed sentence decides the whole result. Turning a spoken phrase into an event with a place and a travel buffer attached matters more to the shape of a day than the elegance of a month view does, and the way that entry works in practice is shown in Entering events, with the wider scope in Features.

What to change first

Start by confirming whether a shared view is enough, because for most people it is and it costs nothing. If rows genuinely need to become real events, build one direction only, run it for a week, and watch whether the free allowance holds before spending anything. If the schedule still does not survive contact with a normal Tuesday, the problem is the missing gaps rather than the sync, and a calendar built around that, such as Caltimate, is the thing to test next.