Calendar connections are now checked the same way mailboxes are. A broken calendar reports as broken instead of quietly failing when someone tries to book.
What changed
Mailboxes had health checks. Calendars did not. A calendar connection could expire and nothing would notice until a prospect clicked a booking link and could not book.
That is the worst possible moment to find out. Someone interested enough to pick a time hits a broken page, and most of them do not try again or write to tell you.
Calendars are now checked on the same schedule as mailboxes. A connection that has stopped working reports as failing, with the reason, before anyone tries to use it.
Why it matters
A booked meeting is the point of the whole sequence. Research, writing, sending, following up: all of it exists to reach a moment where someone chooses a time.
Losing them at that moment is the most expensive failure available, because it happens after every other cost has been paid and after the prospect has already decided to talk to you.
It is also the failure least likely to be reported back. Someone whose booking fails does not email to say the page was broken. They close the tab, and the campaign records no reply.
How to use it
Nothing to set up. Health checks apply to connected calendars automatically.
A failing calendar appears in your connectors with the reason, most often an expired authorisation. Reconnect it and booking works again.
The check runs on a schedule, so a connection that breaks overnight is reported in the morning rather than at the moment it costs you a meeting.
Why calendar connections break
Expired authorisation is the common one. Calendar providers issue access that lasts a fixed period and requires renewal, and the renewal fails if anything about the account has changed.
Password and security changes revoke existing access. Changing your Google or Microsoft password often disconnects everything authorised under it, calendars included.
Permission changes at the organisation level. An administrator tightening what third party applications may access will break connections that were previously fine, and this happens without warning to the individual.
Testing your own booking link
Open your booking link in a private browser window, as a prospect would. You will see exactly what they see.
Check that times appear, that they match your actual availability, and that a booking completes. A link that loads but shows no available times is broken in a way that health checks cannot detect, because the connection is fine and the availability rules are wrong.
Do this after any change to your calendar setup, your working hours, or your account password. Those three changes cause most booking problems.
What health checks do not cover
They confirm the connection works. They cannot tell you your availability rules make sense.
A calendar that is connected but fully booked for three weeks shows no available times and reports perfectly healthy, because it is. So does one where the working hours were set in the wrong time zone.
Those need the manual check above. The health check tells you the pipe is open, not that anything useful is coming through it.
The failure nobody reports
Most product problems reach you because somebody complains. A prospect whose booking page fails is the exception. They are not your customer, they owe you nothing, and the page failed at the exact moment they were doing you a favour by choosing a time.
So they close the tab. The campaign records no reply, the sequence carries on, and nothing anywhere indicates that the most valuable moment in the whole exchange happened and broke.
That is why this needed checking rather than waiting for a report. There was never going to be a report.
When to reconnect
Reconnect as soon as a calendar reports failing. Unlike a mailbox, there is no partial working state to fall back on: a broken calendar connection means nobody can book, full stop.
Reconnecting is the same flow as connecting the first time, and it takes under a minute. The one thing to check afterwards is that your availability came back the way you expect, because reconnecting occasionally resets which calendars are consulted for busy times.
If you connect more than one calendar, check that all of them are still attached rather than just the one that failed.
Booking links inside emails
The links in your sent emails keep working when you reconnect. Reconnecting refreshes the connection behind the link rather than issuing a new link, so emails already in someone's inbox are unaffected.
This matters because a campaign puts booking links into messages that may sit unread for a week. If reconnecting had invalidated them, every fix would have broken every link already sent, which would have been a worse problem than the one being fixed.
What gets checked
The check confirms the connection can still read your calendar and can still write an event to it. Both matter, because a connection that can read but not write shows available times and then fails at the moment of booking, which is the same bad outcome by a different route.
It runs on a schedule rather than continuously, so there is a window between a connection breaking and the failure appearing. That window is short enough to catch nearly everything before it costs a meeting, and continuous checking would mean hammering the provider for no real gain.
Availability rules are the other half
Health checks answer whether the connection works. They cannot answer whether the times you are offering make sense, and in practice that is where more meetings are lost.
The two failures that produce an empty booking page with a perfectly healthy connection are a time zone set wrong and working hours that no longer match reality. Both look correct on the settings screen and both show nothing to the person trying to book.
The private window test catches both, which is why it is worth doing periodically even when nothing has reported a problem.
Availability
Live now on all plans for connected calendars. Status appears alongside mailboxes in your connectors list.