Connecting TickTick to Google Calendar

The hard part of connecting TickTick to Google Calendar is not finding the setting. It is that the setting offers two different connections, and the one chosen determines whether a mistake stays local or writes itself into a calendar other people can see. Most guides show the click path and skip that distinction entirely.

What follows separates the two connections, lists the two decisions worth making before opening the settings panel, explains the duplicate events that show up in the first week, and marks the point where the free plan stops being enough.

Two connections, not one

The path runs through settings, then the import and integration section, then the calendar entry, then Google. Once the account is authorised, two options appear.

Subscribing brings Google Calendar events into the task app, where they appear in the calendar view and in the Today and Next 7 Days smart lists. It is worth being precise about what this does, because it is widely described as read only and the vendor documentation says otherwise: adding, modifying, or deleting an event inside the task app is synchronised back to Google Calendar. What subscribing does not do is reclassify anything. An event stays an event, a task stays a task, and the two sit side by side without either becoming the other.

Two way integration changes the type. It pairs a chosen list with a chosen calendar, so tasks in that list surface in Google Calendar as events, and events created in that calendar arrive in the list as tasks. That is the connection people picture when they search for sync, and it is also the one that can put personal task blocks onto a shared work calendar if the destination is left at its default.

The practical difference is narrower than the labels suggest. Subscribing is the safer option because nothing is reclassified and nothing lands in a list a colleague can read, not because it is incapable of touching a real meeting. Editing the wrong row inside the task app moves the meeting for everyone invited to it.

Two way integration also carries a version floor. TickTick's help documentation states that it requires v7200 or later on Android and iOS, and v5500 or later on Windows, Mac, and the web. When the option simply is not visible, check the application version before investigating permissions or reconnecting the account, because an out of date client hides the control rather than showing it greyed out.

Decide these two things first

The settings screen asks both of these questions, and answering them on reflex is where most later cleanup comes from.

The first is which side is authoritative. Entering events in Google Calendar and letting them appear as context in the task app is one model. Entering everything on the task side and letting the calendar receive it is another. Both work. Doing both at once technically works too, and it is where duplicates come from, because a few minutes of propagation delay is long enough for a person to conclude that the event did not save and type it again.

The second is the destination calendar. A Google account usually holds several calendars, some of them shared with a family or a team, and the sync has to write somewhere. Creating a new, private calendar specifically to receive task blocks takes fifteen seconds and keeps work in progress off other people's screens. It also gives a clean way out: hiding or deleting that one calendar removes every block the integration ever wrote, without touching real meetings.

What actually crosses the boundary

Sync is easy to picture as two identical lists kept in step. It is not. The unit that travels is a task that carries a time, and most of what surrounds that task stays where it was created.

TickTick's help centre describes the mechanism plainly: tasks with time attributes in the selected list are synchronised as calendar events, and events added in Google Calendar are synchronised back as tasks in that list. Two consequences follow from that sentence, and both catch people out in the first week.

The first is that an undated task is invisible on the calendar. A list of forty items where only six carry a date produces six blocks, and the other thirty-four never appear anywhere. That is correct behaviour rather than a failed connection. Anyone whose main complaint is that most tasks did not show up is usually looking at a dating problem, not a sync problem.

The second is that a calendar event has fewer fields than a task. Title, start, end, and notes have obvious counterparts. Priority, tags, list membership, subtasks, and checklist items do not, because a calendar event has nowhere to put them. Those attributes stay intact on the task side and simply do not travel. Editing an event in Google Calendar and expecting a tag or a subtask to survive the round trip is the common version of this mistake.

Selection happens per list and per calendar, and that is the lever worth using deliberately. Enrolling one list rather than the whole account keeps the grid readable, and it keeps private lists out of a destination that other people can open. Adding a new list later does not enrol it automatically, which is worth remembering the first time something fails to appear.

Why the same event shows up twice

Duplicates in the first week are common, and they almost always trace back to one of three causes.

• Both subscribing and two way integration are enabled, so Google events arrive by two routes
• An older automation service connection is still running alongside the official integration
• A phone's built in calendar holds the same Google account and writes into an overlapping destination

Diagnosis takes one click. Open one of the duplicated events and look at which calendar owns it. Two different calendar names means two active routes. The same name on both usually means one copy is a stale record that clears after a refresh.

The fix is ordered: reduce to a single route first, keeping the official integration and switching off the automation service. If copies remain, create a fresh destination calendar, point the integration at it, and delete the old destination in one action. Confirm that the calendar being deleted is private before doing that, since a shared calendar takes other people's events with it.

When nothing moves for hours

Propagation is not instant in either direction, and the delay is the most commonly reported irritation with connections of this kind. Anything under an hour is worth treating as normal. Work through the checks in order rather than reconnecting the account on the first sign of trouble.

Start with the task itself and confirm it has a time on it, since an undated item has nothing to become. Then confirm the list is one of the selected lists and the destination is one of the selected calendars. Then confirm the calendar is actually ticked as visible in Google Calendar, because a hidden calendar produces an empty grid that looks identical to a broken sync. Finally, confirm the same Google account is signed in at both ends. Two accounts on one Mac, one personal and one from work, is the usual explanation for an event that exists but cannot be found.

Reconnecting the account belongs at the end of that list, not the start. Re-authorising can leave a second route running alongside the first, which is exactly how the duplicates described above begin. If the calendar application offers a manual refresh, use it before touching the integration at all.

Subscription addresses behave differently again. There the fetch interval belongs to the receiving application rather than to the source, so a change made in the morning can legitimately take until the evening to show up, and no setting on the sending side will speed it up. A subscription is a viewing mechanism, and treating it as a sync is where most of the frustration comes from.

What the free plan covers

The published limits on the free plan are 9 lists with up to 99 tasks in each. The paid plan raises those to 299 lists and 999 tasks per list, and it is listed at US$49.99 per year, which the same page works out to under US$4.17 a month. The calendar view is described as basic on the free plan and unlimited on the paid one.

Item	Free	Paid
Lists	9	299
Tasks per list	99	999
Calendar view	Basic	Unlimited
Reminders per task	2	5
Checklist items per task	19	199
Attachments per day	1	199
Members per shared list	2	29

The rows that matter for this particular question are the last four rather than the first two. A calendar block created from a task usually wants a reminder before it starts and a second one at departure time, and the free plan stops at two reminders in total. A shared list capped at two members is fine for a couple and not for a team. Vendors revise all of this, so read the current pricing page before committing rather than trusting a table in any article, including this one.

Two things are also worth knowing before paying. Refunds are available within 14 days of purchase when the subscription was bought through Google Play, PayPal, or Stripe, while purchases made through the App Store are handled by Apple. When a subscription lapses, the vendor states that data is fully retained and the account simply reverts to free behaviour, so an expired plan does not put existing tasks at risk.

Sending tasks the other way

The opposite direction, putting tasks onto a calendar rather than pulling events into the task list, is also supported, through a subscription address that any calendar application can register. Google's own documentation draws the distinction between the two ways of connecting an outside calendar.

You can sync your Google Calendar events with other computer applications, like Outlook or Apple Calendar. Source: support.google.com

The same page separates connecting by account, which allows viewing and editing, from connecting by address, which is read only. A subscription address falls in the second category, and the receiving calendar decides how often to fetch it. Google does not expose that interval, so several hours of lag is normal. Subscriptions are for information that settles the day before, not for times that move during the afternoon.

When the calendar side genuinely needs to be writable, the two way integration is the right tool, with the same two rules applied: one route only, and a dedicated destination calendar. Both are trivially reversible, which is what makes them worth setting up correctly the first time.

Turning it off without leaving debris

Disconnecting is not the same as undoing. Events the integration already wrote become ordinary Google Calendar events the moment they are created, and switching the connection off leaves every one of them in place. A calendar full of stale task blocks months later is the usual result of assuming that turning sync off cleans up after itself.

Removal is a three step job, and it is far easier when a dedicated destination calendar was created at the outset.

1. Turn the integration off in the task application first, so nothing new is written while the old records are being cleared.
2. Delete the dedicated calendar in Google Calendar. Deleting a calendar removes every event on it in a single action, which is precisely why the destination must be a calendar that holds nothing else. Confirm it is not shared before deleting, since anyone it was shared with loses those entries too.
3. Remove the application's access from the Google Account linked apps page. Google's instructions are to open the linked apps page, select the app, choose See details, then choose Remove access and confirm. Skipping this leaves an authorisation live for a connection that is no longer in use.

Anyone who enabled sync against a main calendar rather than a dedicated one has a slower path out. Sorting or filtering by the calendar that owns the events and deleting them in batches is the only safe route, because a bulk delete that catches real meetings cannot be undone.

What appears once tasks are on the grid

Something changes as soon as tasks occupy real time on a calendar. A grid that used to hold four meetings now holds four meetings and eleven blocks, and the honest conclusion is that the day was always this full. The blocks were simply invisible while they lived in a list.

What still is not on that grid is movement. A day with appointments in two locations breaks the moment one of them runs long, and no amount of sync accuracy prevents it, because travel was never entered as an event. Whether the return leg gets reserved, and whether the alert fires at departure time rather than start time, is a property of the calendar rather than of the integration, and Travel time covers what changes when it is handled properly.

The other thing worth measuring is how long entry takes. The reason for connecting two applications is usually to have one place to type into, which makes the speed of that one place the ceiling on the whole arrangement. Converting a spoken half sentence into an event that already carries a location and a buffer does more for a working day than any view layout does. How that entry behaves is shown in Entering events, and the surrounding scope sits in Features.

What to change first

Start with subscribing, since it answers most of the original need without turning tasks into events on anyone else's screen. Move to two way integration only when tasks genuinely have to reach a phone or a colleague, and create the dedicated destination calendar before enabling it. If the schedule still falls apart after everything is visible in one place, the missing piece is the space between commitments rather than the connection, which is the problem Caltimate is built around.