Connecting Notion to Google Calendar: a date is not an event

The appeal is obvious: the deadlines in a Notion database should appear in the calendar you actually look at. The difficulty is that a date property in a database and an event in a calendar are different kinds of object, and most of the friction in building this comes from pretending otherwise.

A deadline is a point; an event occupies time. A task has a status; an event has attendees and a response. Deciding which of those differences matter for your case determines whether this is a small one-way automation or an ongoing maintenance problem.

What we'll cover

• What each system can express
• Deciding the direction
• What breaks in two-way sync
• Building it with CodeWords
• Which rows should become events
• What the event should say
• Recurring items, which are the hard case
• Time blocking, which is the real request
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

What each system can express

Notion holds a date or a date range on a property, with or without a time.

A calendar event has a start and an end, a timezone, attendees, a location and a response state.

Notion has status, assignee and relations, none of which a calendar event can carry meaningfully.

A calendar has invitations and availability, which a database row cannot represent.

All-day versus timed is a real distinction in a calendar and frequently unspecified in a database.

The intersection is small: a title, a time, and a link. Anything beyond that is being forced into a shape that does not fit.

Deciding the direction

Notion to calendar is the common case: deadlines and scheduled work appearing where you look.

Calendar to Notion is rarer and is usually about logging what happened rather than planning.

One direction is a small automation. Two directions is a conflict-resolution problem with no natural answer.

Pick the authoritative system per field, if you must do both — dates owned by one, everything else by the other.

Most people want one-way and ask for two-way because it sounds more complete.

Say which is authoritative in the database itself, so the person editing knows which edit will survive.

What breaks in two-way sync

Moving an event should move the date, which is reasonable, and it means a calendar drag silently edits a database record.

Deleting an event is ambiguous. It may mean the task is cancelled or that somebody tidied their calendar.

Loops form easily, with each system reacting to the other's change.

Notion's edit granularity is coarse, so detecting what actually changed is harder than it sounds.

Attendee responses have no home in the database, so accepting or declining is lost.

Recurring events do not map to anything a database row can express, which is where most implementations break.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so Notion, Google Calendar and your notifications can meet in one automation.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which rows become events, in which direction, and what happens on a change.
3. Authorize the connections — Notion and Google Calendar.
4. Describe the exceptions: a row with no date, a completed task, a deleted event, a recurring item.
5. Run it over one database and check the resulting calendar before scaling.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Which rows should become events

Not everything with a date, which is the default and produces a calendar nobody can read.

Filter by status, so completed and cancelled items do not appear.

Filter by assignee, so somebody's calendar holds their work rather than the team's.

Separate calendars by type, so deadlines and scheduled sessions can be shown and hidden independently.

Decide about the distant future. A database of items dated months out fills a calendar with things that are not decisions yet.

Use a dedicated calendar, never the primary one, so the whole thing can be turned off without collateral damage.

What the event should say

A title that is readable out of context, since it appears next to meetings rather than next to other tasks.

The status in the title where it matters, because a calendar shows no other indication.

A link back to the Notion page, which is the single most useful field and is often omitted.

Deadlines as all-day, and scheduled work as timed, which is the distinction that makes the calendar legible.

Duration that means something. An arbitrary hour block for every task makes the calendar look full of commitments that are not.

Not the whole page content, which is unreadable in a calendar entry and goes stale immediately.

Recurring items, which are the hard case

Notion recurrence and calendar recurrence are different features with different semantics.

A recurring database template generates rows; a recurring event is one object with a rule. They do not correspond.

One-off changes to an occurrence have nowhere to live on the database side.

Generate individual events rather than recurring ones, which is more records and far fewer surprises.

Bound the horizon — generate a few months ahead rather than indefinitely — and extend on a schedule.

Handle the series ending, since generated events for a stopped recurrence will otherwise persist indefinitely.

Time blocking, which is the real request

Most people asking for this do not want their deadlines in a calendar. They want to know whether the work fits in the time available, which is a different thing and is what the calendar is actually good at.

A deadline tells you when something is due, not when you will do it, and a calendar full of due dates answers the wrong question.

Block the work, not the deadline. An estimate of effort placed in real time is what reveals whether the week is possible.

Let the estimate come from the database, where it may already exist as a property, rather than defaulting every task to an hour.

Place blocks around existing commitments, which is the part automation does well and people do badly.

Leave it editable. A block that cannot be moved without the automation putting it back is worse than no block.

Compare planned against actual occasionally, which is uncomfortable and is the only way estimates improve.

Making it survive

Store the event id on the Notion row, which is what makes updating rather than duplicating possible.

Make writes idempotent, since a retry that creates a second event is the common failure here.

Handle the deleted row and the deleted event explicitly, and decide which direction a deletion propagates — if either.

Respect Notion's rate limits, which are stricter than people expect on large databases.

Report the outcome: rows processed, events created, updated, skipped, and any orphans.

Limits worth knowing about

Notion's API is rate limited and a large database sync is slow.

Property types are strict, and a date property containing a range behaves differently from a single date.

Timezones come from the workspace and the calendar and may disagree, which produces events an hour out.

Google Calendar has quotas on writes, which a bulk generation run will reach.

Notion's own calendar views exist, and for many people they are sufficient — worth checking before building a sync at all.

What to build first

One-way, filtered, into a dedicated calendar: incomplete tasks assigned to one person with a date in the next few weeks, as all-day entries with a link back to the page. It is small, it can be turned off without consequence, and it answers whether seeing this in a calendar is actually useful before any effort goes into the harder version.

Two habits make the difference. Store the calendar event id on the Notion row from the start, since without it every run creates duplicates and retrofitting the link across an existing calendar is tedious. And generate individual events rather than recurring ones, because the two systems mean different things by recurrence and that mismatch is where these integrations break.

Frequently asked questions

Why is syncing Notion dates to Google Calendar harder than it looks?

Because a date property and a calendar event are different objects. A deadline is a point and an event occupies time; a task has status and relations, an event has attendees and responses. The overlap is a title, a time and a link.

Should the sync be one-way or two-way?

One-way for almost everyone. Two-way is a conflict-resolution problem with no natural answer — deleting an event is ambiguous, loops form easily, and attendee responses have nowhere to live in a database.

Which rows should become calendar events?

Not everything with a date. Filter by status and assignee, use a dedicated calendar rather than the primary one, and decide deliberately how far into the future to generate.

How should recurring items be handled?

Generate individual events rather than recurring ones. Notion recurrence and calendar recurrence are different features with different semantics, and one-off changes to an occurrence have nowhere to live on the database side.

What should the calendar event contain?

A title readable next to meetings rather than next to tasks, the status where it matters, and a link back to the Notion page — which is the most useful field and the most often omitted.

Why do my events appear an hour out?

Usually a timezone disagreement between the Notion workspace setting and the calendar, particularly around daylight saving transitions.

How do I avoid duplicate events?

Store the calendar event id on the Notion row. Without it every run creates new events, and retrofitting the link across an existing calendar is tedious work.

Do I need this at all?

Notion has its own calendar views, which are sufficient for many people. Worth checking before building a sync, since the maintenance is permanent and the view is not.

Do I want deadlines in my calendar, or time blocks?

Usually time blocks. A deadline tells you when something is due, not when you will do it, and a calendar of due dates answers the wrong question — whether the work fits in the week is what the calendar is good at.

Where should the block duration come from?

An estimate property in the database, if one exists. Defaulting every task to an hour fills the calendar with commitments that are not real and makes the whole view untrustworthy.

Should completed tasks stay in the calendar?

Filter them out. A calendar showing what you already finished is history in a place designed for commitments, and it makes the remaining entries harder to read.

Why is a dedicated calendar better than the primary one?

Because it can be hidden or deleted without collateral damage. A sync writing into a primary calendar is difficult to undo and hard to separate from real commitments when it goes wrong.

Related reading

• Automating meeting scheduling
• Notion and CodeWords
• Automating task assignment