What does 'could not fetch the URL' mean in Google Calendar?

Google's servers requested the URL and did not receive something parseable as a calendar. Common causes are a revoked or regenerated Outlook publish link, a Microsoft sign-in page returned instead of the feed, an endpoint that rejects requests without browser-like headers, and malformed ICS content. Opening the URL in a private browser window reproduces what Google saw.

Why does an ICS feed work in Google Calendar but fail in Apple Calendar?

Apple Calendar validates iCalendar content more strictly and rejects files Google will partially accept. The usual cause is malformed time zone data, such as a VTIMEZONE component that does not define the TZID the events reference. Repairing the time zone references generally satisfies both clients.

Can a proxy bypass a Microsoft 365 tenant that blocks calendar publishing?

No. If the tenant does not allow anonymous calendar publishing, no public feed exists to fetch and there is nothing for a proxy to relay. This is an administrative sharing policy rather than a technical fault.

The Outlook ICS feed won't load in Google Calendar

Q: The ICS URL works in my browser but Google Calendar shows an empty calendar. Why?

Either the browser is signed in to Microsoft so the link is not genuinely public — a private window will show this — or the publish endpoint returns an HTML error page to clients that do not send browser-like request headers, which Google does not. A proxy that sends browser-shaped headers upstream retrieves the real calendar and passes it to the subscriber.

Google accepts the URL and then shows an empty calendar, or refuses it outright with "could not fetch the URL". Apple Calendar tends to be blunter and returns an error. Six things cause this, and you can tell them apart in about a minute.

Start here: open the .ics URL in a private/incognito browser window. If you see a wall of text beginning with BEGIN:VCALENDAR, the link is fine and the problem is on the subscriber side. If you get a sign-in page, an error page, or a download that turns out to be HTML, the link itself is the problem — and no calendar app will ever be able to read it. The private window matters: in your normal browser you are signed in to Microsoft, so a link that only works for you looks like it works for everyone.

The six causes, most common first

1. You copied the HTML link instead of the ICS link

Outlook's publish dialog offers two links per calendar. The HTML one opens a web page for humans; the ICS one is the feed. They look similar and sit next to each other. If your URL ends in /calendar.html or contains /published/ without .ics, that is the problem. Go back to Settings → Calendar → Shared calendars and copy the other one.

2. The publish link was regenerated or revoked

Every time you stop and restart publishing a calendar in Outlook, the URL changes and the old one dies. Anyone still subscribed to the old URL silently stops receiving updates, and the calendar eventually goes stale or empty rather than showing an error. A private-window test on the old URL returns an error page. The only fix is to re-publish, take the new link, and re-subscribe everywhere.

3. The calendar is published as "availability only"

Outlook lets you publish limited detail. At the availability-only level the feed contains busy blocks with no titles — which can look like an empty or broken calendar in Google when there is nothing to show. Re-publish with Can view all details.

4. The endpoint answers browsers but not calendar clients

Some Microsoft publish endpoints have been observed returning an HTML error page instead of the calendar when the request does not carry browser-like headers. Google and Apple do not send a browser User-Agent, so they get the error page, fail to parse it, and report an empty calendar or a fetch failure — while the exact same URL works perfectly when you paste it into a browser. This is the frustrating one, because every check you can do by hand passes.

A proxy fixes it by sending browser-shaped request headers upstream and handing the real calendar back to the subscriber. The feed proxy does this on every request; you do not need to turn anything on.

5. The tenant blocks anonymous calendar publishing

Microsoft 365 administrators can disable calendar sharing outside the organisation. If publishing is disabled the option may be missing, greyed out, or produce a link that only ever returns an error to signed-out requests. Nothing outside the tenant can work around this, and a proxy cannot either — it is an authorisation decision, not a technical fault. Ask your administrator about the sharing policy.

6. The feed is malformed enough for the subscriber to reject it

Missing required properties, a VTIMEZONE that does not match the TZID used on events, or truncated output will make a strict client refuse the whole file. Apple Calendar is stricter than Google here, so "works in Google, HTTP 400 in Apple Calendar" points squarely at this. Run the feed through diagnostic mode to see what a parser actually finds in it.

Tell them apart in one minute

Private-window test returns…	Cause	Fix
Text starting `BEGIN:VCALENDAR`, with your events	Link is good — subscriber-side issue (cause 4 or 6)	Subscribe through the proxy; check the diagnostic output.
Text starting `BEGIN:VCALENDAR`, but no events	Availability-only publishing, or an empty calendar (cause 3)	Re-publish with Can view all details.
A Microsoft sign-in page	Link is not public (cause 2 or 5)	Re-publish; if it recurs, check the tenant sharing policy.
A rendered calendar web page	HTML link, not ICS (cause 1)	Copy the other link from the publish dialog.
An error page or HTTP 404	Link revoked (cause 2)	Re-publish and re-subscribe everywhere.

If you would rather not eyeball raw ICS, paste the link into the generator and press Diagnose my feed. It reports the HTTP status, whether the response was actually a calendar or an HTML page in disguise, and what it found inside.

webcal:// versus https://. A webcal:// URL is the same URL with a scheme that tells the operating system to hand it to a calendar app. Google Calendar wants https:// in the "From URL" box. If your link starts with webcal://, replace that prefix with https:// — nothing else about the URL changes.

Questions

Google Calendar says "could not fetch the URL". What does that mean?

Google's servers requested the URL and did not get something they could parse as a calendar. That covers a revoked link, a sign-in page returned instead of the feed, an endpoint that rejects non-browser requests, and a malformed file. Reproduce it by opening the URL in a private browser window — whatever you see there is what Google saw.

The URL works in my browser but Google Calendar shows nothing. Why?

Two likely reasons. Either your browser is signed in to Microsoft and the link is not actually public, which a private window will reveal, or the endpoint is serving an HTML error page to clients that do not send browser-like request headers. Google does not send them; a proxy that does will get the real calendar and pass it through.

Why does the same feed work in Google Calendar but fail in Apple Calendar with an error?

Apple Calendar validates more strictly and rejects a file Google will partially accept. That points at malformed content — commonly a VTIMEZONE that does not define the TZID the events actually use. Repairing the time zone references usually makes both clients happy.

Can a proxy get around my company blocking calendar publishing?

No, and you should be sceptical of anything that claims it can. If the tenant does not permit anonymous publishing, the feed does not exist to fetch — there is nothing for a proxy to relay. That is an administrative policy, not a bug.

My calendar loaded once and is now empty.

Almost always a publish link that was regenerated. Subscriptions to the old URL fail quietly rather than warning you. Test the URL in a private window; if it errors, re-publish in Outlook and re-subscribe with the new link.