Calendar Feeds

What it does

Each linked calendar shows its events on the Calendar page in the color you pick, sitting alongside ResearchOS tasks and events. Clicking an event opens a popup with the title, time, and any location, notes, or link the source calendar published.

Linked calendars are read-only. ResearchOS fetches a public iCal (ICS) URL on a timer and overlays the events. It never writes back to Google, Outlook, or Apple. To edit an event, open it in its source app, and the change syncs into ResearchOS on the next 15-minute refresh.

Open the Linked Calendars panel

Go to the Calendar page. The Linked Calendars button sits top-right, next to + New Event. A small blue badge on the button counts how many subscriptions are currently turned on.

Add a calendar by ICS URL

1. Click Linked Calendars, then scroll the panel down to Or paste a public iCal / ICS URL.
2. Pick the source from the Provider dropdown (iCloud / Apple Calendar, Google Calendar, Outlook / Office 365, or Other (any public iCal URL)).
3. Type a Label (this is what shows up on the Calendar page) and click one of the 10 swatches under Color.
4. Paste the URL into the ICS URL field and click Add Calendar. The button shows Testing… while ResearchOS fetches the feed to confirm it parses.
5. If the feed parses but contains no events within a ±2-year window of today, you'll get a confirmation dialog before the subscription saves. That's the normal case for stale or empty calendars.

Where to copy the ICS URL from

Inside the panel, the Where do I find this URL? link expands a per-provider checklist that matches whichever Provider you have selected. The summaries below are the same steps in long form.

Google Calendar

1. Open calendar.google.com in a desktop browser.
2. Click the gear → Settings → Settings for my calendars.
3. Pick the calendar you want to share in the sidebar.
4. Copy Secret address in iCal format for a private calendar, or Public address in iCal format if the calendar is already public.

Outlook / Microsoft 365

1. Open Outlook on the web → Settings → Calendar → Shared calendars.
2. Under Publish a calendar, pick the calendar, choose Can view all details, and click Publish.
3. Copy the ICS link Outlook generates.

iCloud / Apple Calendar

1. Open the Calendar app on macOS, or sign in to iCloud.com in a browser.
2. Right-click the calendar in the sidebar → Share Calendar → Public Calendar.
3. Copy the share link. It starts with webcal://, which is fine to paste as-is.

Any other public iCal feed

Pick Other (any public iCal URL) in the Provider dropdown. That covers university course schedules, lab seminar series, conference timetables, sports schedules, anything that ends in .ics or starts with webcal://.

After a calendar is connected

Each subscription becomes a row in the Connected list at the top of the panel. Here's what each row gives you.

• The label you gave it, plus a small uppercase tag with the provider type.
• The full ICS URL, truncated to one line.
• A Last synced timestamp once ResearchOS has fetched the feed at least once.
• A 5-swatch color strip on the left edge of the row. Click any swatch to recolor that calendar's events on the grid.
• An On / Off checkbox to hide a calendar's events without removing the subscription.
• A red Remove link to drop the subscription. A confirmation dialog reminds you that ResearchOS events aren't touched.

If a feed fails to fetch three times in a row (a usual sign the share URL expired or was revoked), ResearchOS stops auto-retrying it and the row shows Stopped syncing — the link may be broken or expired. Click Retry now after fixing the link, or remove the subscription and re-add it with a fresh URL. A one-off hiccup instead shows a quieter note that it will retry on its own.

How often feeds refresh

ResearchOS refetches each feed at most once every 15 minutes per browser session. The fetch goes through a small server proxy (the same Vercel function that bypasses CORS for Google, Outlook, and iCloud), and the proxy caches the response on its own edge cache for another 15 minutes. Back-to-back page loads don't hammer the source calendar's servers as a result.

If you just added an event in the source calendar and want it on the ResearchOS grid right now, hard-refresh the browser tab or wait out the 15-minute window.

What URLs the server proxy will fetch

The proxy is the small server endpoint that fetches each ICS URL on your behalf, because browsers can't fetch calendar.google.com directly (Google doesn't set the right CORS headers). The proxy refuses a few classes of URL outright so it can't be used to scan internal infrastructure.

• Anything that isn't https:// (so no http://, no file://, no ftp://). Plain http:// is rejected outright for security. The webcal:// prefix is rewritten to https:// first, so iCloud URLs still work.
• localhost and the loopback range 127.0.0.0/8.
• The private IPv4 ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
• Link-local 169.254.0.0/16 and the IPv6 equivalents (fe80::/10, fc00::/7, ::1).
• Responses that don't start with BEGIN:VCALENDAR. This catches the case where a calendar share URL redirects to an HTML sign-in page instead of returning iCal text.

If a paste fails with one of those errors, double-check that the URL is the public ICS variant of the calendar (not the regular web-app share link).

Recurring events

Repeating events (e.g., a weekly seminar) are expanded into one chip per occurrence inside a ±2-year window around today. That keeps a 20-year-long daily recurrence from spawning ~7,300 chips on the grid. If you scroll the calendar more than two years backward or forward, repeating events from external feeds will stop showing up until you refresh the page from a closer date.

Want to edit linked events from ResearchOS?

Linked calendars are read-only by design. To make changes, open the event in its source app (Google Calendar, Outlook, Apple Calendar). Your edit shows up in ResearchOS on the next 15-minute refresh. Earlier ResearchOS builds had an OAuth-backed two-way sync for Google and Outlook. That surface was removed (2026-05-14) in favor of keeping the integration simple and credential-free. The ICS subscription flow described here is the only supported path now.