Outlook calendar link: sharing a week without the account

Four completely different things get called an Outlook calendar link, and the instructions for one produce nothing useful for the others. There is the address that lets another calendar app subscribe to a schedule. There is the web page address that shows a calendar in a browser. There is the invitation that grants another Outlook user access to a calendar. And there is the add-to-calendar link dropped into an email so a recipient can save one event.

Deciding which of the four is needed takes ten seconds and saves an afternoon. The question that separates them is simple: does the other person need to keep seeing changes, or do they need one thing once.

Which link to create

	What the recipient gets	Keeps updating	Needs an account
ICS link	A subscribable feed	Yes, on a delay	No
HTML link	A web page in a browser	Yes, when reloaded	No
Sharing invitation	The calendar inside their Outlook	Yes	Yes
One event as a file	A single event to save	No	No

The first two come from publishing. Microsoft's path is to open Settings in Calendar view, select Shared calendars, and under Publish a calendar choose which calendar to publish and how much detail people can see, then publish.

Both addresses appear together and they are not interchangeable. Microsoft describes the HTML link as one recipients can copy and paste into a browser to view the calendar in a new window. The ICS link is the one a calendar application consumes, and Microsoft spells out the two things a recipient can do with it: download the ICS file and import it, which adds the events but sends no future updates, or use the ICS link to subscribe, which shows the calendar alongside their own and delivers updates automatically.

The distinction between importing and subscribing is the single most consequential choice in this whole area, and Microsoft states it plainly in its own documentation. Importing an ICS file gives a snapshot of the events at the time of import, and the calendar does not refresh those events afterwards even when the owner makes changes. Subscribing connects the calendar, so changes the owner makes reach the subscriber.

Microsoft's own examples are a good guide to which to pick. Import suits things that will not change, like tide tables or phases of the moon. Subscribe suits things that change often, like a school calendar.

How much the link reveals

The detail level chosen at publish time is a ceiling, and nothing downstream can raise it. A recipient whose subscription shows only grey blocks is not misconfigured. They are seeing what was published.

The sharing path exposes the same decision more explicitly, with four levels plus a delegate option. The lowest shows only when the calendar owner is busy, and Microsoft notes it does not include details such as the event location. The next adds titles and locations. The next shows all the details of every event. Above those sits editing, and a delegate setting that adds the ability to share the calendar onward and act on meeting requests.

Two behaviors surprise people often enough to be worth stating.

Private items stay private regardless. Microsoft states that calendar items marked private are protected, that most people the calendar is shared with see only the time of a private item and not its title, location or other details, and that a recurring series marked private still shows its recurrence pattern. So a published calendar can be set to show full details and still contain unnamed blocks.

Edit access does not travel through an ICS link. Microsoft is explicit: ICS calendars are read-only, so even if edit access is granted to other people, they will not be able to edit the calendar. Editing requires the account route, not the link route.

The invitation route, and why it often is not available

The third kind of link is not a URL at all. It is a sharing invitation sent to a named person, and it is the only route that can grant editing or delegate rights. In Calendar, the toolbar's Share button starts it, an address is entered, a permission level is chosen, and the recipient accepts from the message to add the calendar to their own view.

Three limits decide whether this is even an option. Microsoft notes that calendar sharing may not be available for an account at all, or may be limited to people inside the organization, depending on how the organization is configured. It also notes that calendars owned by other people cannot be shared onward. And it warns that when a calendar is shared with someone not using Outlook on the web, for example someone using Gmail, they will only be able to accept the invitation with a Microsoft 365 or an Outlook.com account.

That last point catches people out constantly, because it looks like a delivery failure. The invitation arrives, the recipient clicks Accept, and nothing happens. For anyone outside that account family, the published ICS link is the route that works, at the cost of editing.

Permissions granted this way are changed or revoked from the same place. Right-click the calendar under Calendars, choose Sharing and permissions, and either pick a new level or remove the person. Microsoft notes that once removed, their copy of the calendar no longer syncs or receives updates.

There is a fourth behavior that is not a setting but a property of the mechanism. A published ICS address is a secret URL. Anyone holding it can read whatever detail level was published, with no sign-in. That is what makes it work across companies and platforms, and it is also the reason it should be treated like a password rather than pasted into a group chat.

Adding the link on a Mac

On the Mac the ICS address goes into Apple Calendar through File > New Calendar Subscription. Paste the address, click Subscribe, and the rest of that dialog decides how the subscription behaves for the next year.

Location chooses where the subscription lives. Apple's guide notes that choosing the iCloud account makes the calendar available on all computers and devices set up with iCloud, while On My Mac saves it on that computer only. This one setting explains almost every case of a subscribed calendar appearing on a Mac and never on a phone.

Auto-refresh sets how often the feed is re-read, chosen from a pop-up menu. Set it deliberately. A feed left at a long interval is the usual reason a moved meeting appears hours late.

The Remove checkboxes strip the feed's event attachments and alerts. Apple's guide notes that to get a subscribed calendar's attachments or alerts, those checkboxes must be deselected. There is also an Ignore alerts option, which is usually the right choice for a calendar that is only being watched, since another person's reminder settings should not be making this Mac buzz.

To change any of it later, Apple's instruction is to click the calendar's name and choose Edit > Get Info. To stop, Control-click the calendar in the list and choose Unsubscribe.

Two troubleshooting facts are worth keeping. Apple documents that a warning symbol next to a published, shared or subscribed calendar means Calendar is unable to connect to the calendar account, and suggests checking the connection and confirming the calendar has not been deleted or moved, with Control-click > Get Info showing the address still being requested. And View > Refresh Calendars forces an update rather than waiting for the interval.

How long the delay really is

The most common complaint about calendar links is that they are broken, and the most common cause is that they are not.

For the direction where Outlook is the subscriber, Microsoft publishes actual figures, and they are longer than most people assume. An update can take more than 24 hours, although updates should happen approximately every 3 hours. The same page repeats the warning for subscribing from a web address: whenever events change on an iCal, it can take more than 24 hours for the calendar to update.

For the direction where Outlook is the publisher, Microsoft is honest that the answer is not in its hands. How often a shared ICS calendar syncs depends on the email provider of the person it was shared with.

Two conclusions follow. A subscribed calendar is accurate to within a few hours, not to the minute, so it should not be the source of truth for anything happening today. And when a definite answer is needed now, refresh manually instead of debugging a feed that is working as documented.

Apple's guide adds a useful counterpart for account-based calendars. Refresh frequency is set per account under Calendar > Settings > Accounts, and one of the options is Push, which updates the account automatically when a change is made on any device using that account or when someone changes a shared calendar in it. Push and a subscribed feed are different mechanisms, and only one of them is fast.

Sending one event rather than a calendar

Sometimes the request is much smaller than a calendar link. Someone needs one event on their calendar, and a subscription is a heavy answer to that.

The mechanism for this is a calendar file rather than a live address. An event exported as an ICS file and attached to a message can be opened and saved by any mainstream calendar application, which is why event confirmations from booking systems arrive that way. Because it is an import rather than a subscription, Microsoft's rule applies: the recipient gets a snapshot, and later changes do not reach them. Anything likely to move needs a fresh file and an explanation, or a real invitation.

When the event is a meeting with the recipient in it, an actual invitation is better than a file, because it carries responses back. A file tells nobody whether the person is coming.

Which calendar should own the link

The decision underneath all of this is which calendar holds the real schedule. A published link is only as good as the calendar behind it, and a calendar split across two applications produces a link that is wrong in ways the recipient cannot see.

That is also the argument for keeping the reading and the planning in one native application on the Mac, with outside calendars overlaid as subscriptions rather than copied in. Holiday feeds, a partner's published calendar and a work schedule can all sit in one day column as subscribed ICS and webcal feeds while only one of them is the calendar being written to.

There is a second reason to be deliberate here, which the delay figures make clear. Nobody should be publishing a link they would not want read three hours out of date. If a link needs to be minute-accurate, it is the wrong mechanism, and the honest answer is a booking page that computes open slots from the live calendar at the moment someone looks. It is worth comparing which calendars can do that natively before building a workflow around a feed.

What to change first

Decide whether the recipient needs updates. If yes, publish and send the ICS link, and tell them to subscribe rather than download. If no, send one event as a file and stop.

Then treat the refresh interval as a real setting on both ends, and keep one calendar as the one that gets written to. Caltimate reads subscribed feeds alongside a live Google Calendar in one view, with a free 14 day trial and no card required.