The server responded with an error in Mac Calendar

The alert usually arrives at the worst moment. A meeting gets moved, the change is typed into the calendar on the Mac, and a grey box appears saying the server responded with an error. Sometimes it names an account. Sometimes it names nothing at all. Either way the edit sits on screen looking saved, and there is no way to tell from the window whether the other people invited to that meeting will ever see it.

This is not a single fault with a single fix. The message is a relay of whatever a remote calendar server said back, compressed into one sentence that discards the detail. Knowing which server is talking, and what it was refusing to do, turns a vague failure into a short list of things worth changing.

What the message is actually reporting

The calendar app on a Mac is a front end. It does not own the events. Events live on Google, on iCloud, on an Exchange server, or on some other CalDAV host, and the app keeps a local copy in sync with them. When a change is made locally, the app sends it upstream. When the upstream host rejects that request or answers with something unexpected, the app has to say so, and the wording it uses is deliberately generic.

That generic wording hides the useful part. A refusal because a token expired, a refusal because the calendar is read only, and a timeout because the network dropped mid request all surface identically. So does a server that answered correctly but slowly enough that the request was abandoned.

Two consequences follow, and both matter more than any individual fix.

The event may or may not have been written. A rejected request means nothing changed upstream. A timeout means the change might have landed and the confirmation was lost. Before repeating an edit, it is worth opening the same calendar in a browser and looking at the actual state on the server.

The second consequence is that the fix depends entirely on which account failed. Repairing an expired Google authorisation does nothing for an Exchange calendar that is refusing writes because of a permission change, and reinstalling the app does nothing for either.

The accounts that produce it, and why

Four kinds of account cover almost every instance of this message on macOS, and each fails for its own characteristic reason.

Account type	Typical cause	Where the real fix lives
Google	Authorisation revoked or expired, or a workspace policy change	System Settings, Internet Accounts
iCloud	Service interruption, or a signed out Apple Account	Apple Account status and system status
Exchange	Password rotation, mailbox permission change, or autodiscover failing	The mail server administrator
Other CalDAV	Wrong server path, an expired app password, or a read only share	The provider's account settings

Google accounts are the most common source, and the reason is structural. Access is granted by a token rather than by a stored password, and tokens are revoked when a password changes, when two factor settings change, when an administrator tightens app access for a workspace domain, or simply when enough time passes without use. Nothing is broken on the Mac. The permission slip has been withdrawn, and the app is reporting the refusal it received.

Exchange behaves differently. Its failures cluster around permissions rather than tokens: a shared calendar that was moved to read only, a delegate access that lapsed, a mailbox migrated to a new host while the Mac still points at the old one. Those cannot be repaired from the Mac at all.

Subscribed calendars deserve a separate mention. A read only feed pulled from a URL, such as a public holiday calendar or a colleague's published availability, will report a server error the moment that URL moves or the publisher takes it down. The calendar keeps showing its last known contents, which is why the failure can go unnoticed for weeks.

Isolating the account in ten minutes

Guessing is expensive here because several of the plausible fixes are destructive. The faster route is elimination.

Find out which calendar is complaining

In the calendar list on the left, a failing account is usually marked with a warning symbol next to its name. Clicking it shows a longer message than the alert did. If nothing is marked, quitting and reopening the app forces a fresh sync attempt and makes the failing account announce itself.

Check the same calendar somewhere else

Open the account in a browser and look for the event that failed. If the change is there, the problem is the confirmation path, not the write. If it is not there, the write genuinely failed. This single check decides whether anything needs to be re entered, and it takes under a minute.

Confirm the account still has permission

In System Settings, under Internet Accounts, select the account and confirm that Calendars is still enabled and that no re authentication prompt is waiting. For a Google account, signing out and back in reissues the token and resolves a large share of these errors on its own.

Rule out the obvious environment

A captive network portal at a hotel or a conference venue, a VPN that blocks outbound calendar traffic, or a system clock that has drifted far enough to invalidate certificates will all produce this error against a server that is perfectly healthy. Apple publishes service status information at support.apple.com, and Google does the same for its calendar service at support.google.com.

Fixes that hold, and fixes that come back

The repair worth doing depends on whether the cause is a credential, a permission, or a cached state.

Removing and re adding the account in Internet Accounts is the strongest general fix, because it clears both the stored credential and the local cache for that account. It is safe in the sense that the events themselves live on the server. It is not free, because local alarm settings and per calendar colours are reset, and everything has to download again.

Toggling Calendars off and on for one account is the gentler version of the same idea, and it resolves a surprising number of stale token cases without touching anything else.

Deleting the local calendar cache is a heavier step and is mostly warranted when one account syncs correctly and another refuses no matter what, or when the app hangs on launch as well as erroring. It should never be the first move.

What does not hold is repeating the failed action. If a server refused a write once, sending it again produces the same refusal, and each retry adds another alert. Similarly, a fix applied to the Mac cannot survive a server side cause. When an administrator has changed mailbox permissions, the error will return within hours of any local repair.

The detail the alert leaves out

Behind the one sentence in the alert there is almost always a longer answer from the server, and finding it changes the guess into a decision.

The first place it surfaces is the calendar list itself. A failing account carries a small warning symbol beside its name, and clicking that symbol produces a longer description than the modal ever shows. It often names the calendar, and sometimes it names the operation that failed, such as a write to a specific event.

The second place is the system log. Calendar sync on macOS runs through a background agent rather than through the visible app, and that agent writes what it is doing. Opening Console, filtering on the calendar agent process, and reproducing the failure gives the underlying response rather than the summary of it. This is more effort than most situations justify, but it is decisive when an account fails intermittently and nobody can say why.

What is worth looking for in either place is which family of refusal occurred, because the families map cleanly onto different fixes.

A refusal for authentication means the credential is no longer accepted, and the repair is to re authorise the account. A refusal for permission means the credential is fine and the account is not allowed to do that particular thing, which is an administrator question rather than a Mac one. A server fault, where the host itself failed rather than refusing, means nothing on the Mac needs changing and the correct action is to wait and retry later. A request that simply never completed points at the network between the two, not at either end.

Three different repairs, one identical alert. That gap is the whole reason this error is frustrating rather than merely inconvenient.

Shared, delegated, and subscribed calendars

A large share of these errors involve calendars that belong to somebody else, and those behave differently enough to deserve their own treatment.

A shared calendar can be granted at several levels. Read only access shows every event and refuses every change. Write access allows edits. Ownership allows deleting the calendar itself. The failure people hit most often is trying to move or edit an event on a calendar that was quietly downgraded to read only, usually when the owner tidied up their sharing settings. Nothing on the Mac indicates this in advance. The event looks editable, the edit is accepted locally, and the server refuses it a moment later.

Delegated access on Exchange has the same shape with an extra layer. Delegation is granted per mailbox and can lapse when a role changes, when a person leaves, or when a mailbox is migrated. The calendar keeps appearing in the sidebar after the permission has gone, which is why the first symptom is an error rather than a disappearance.

Subscribed calendars are the quietest failure of all. A subscription pulls from a URL on a schedule, and the app cannot write to it at all. When the publisher changes the address, moves to a new tool, or stops publishing, the subscription reports a server error on every refresh cycle and keeps displaying the last successful download indefinitely. Somebody working from a stale holiday feed can be months out of date without a single visible sign beyond an alert that has become background noise.

The rule that follows is simple. If the failing calendar is not owned by the account holder, the fix is a conversation, not a setting. Confirm the access level with whoever owns it before doing anything destructive on the Mac.

When the front end is the thing to change

There is a category of this problem that is not a fault at all. Some accounts are simply slower or stricter than others, and an app that surfaces every hiccup as a modal alert will interrupt the day repeatedly even when the underlying data is fine. Whether that is acceptable depends on how many accounts are attached and how much of the working week runs through them.

Two questions sort this out. First, how many separate calendars are attached to this Mac, and are they all still needed? A stack of subscribed feeds that nobody reads is a stack of things that can fail. Second, when a sync error does appear, does the app say which account and what happened, or does it hand over a single sentence with nothing actionable in it?

An app that reports the account name and the underlying reason turns a ten minute investigation into a ten second one. That difference in error handling is one of the things worth checking on the page that sets calendars for the Mac side by side, compared with other calendars, and it is easy to overlook next to feature lists. The other thing worth checking is how quickly an event can be entered again once the sync recovers, which is covered under entering events.

What to change first

Start by confirming in a browser whether the failed change actually reached the server, because that decides whether anything needs re entering at all. Then sign the affected account out and back in under Internet Accounts, which resolves most token expiry cases without any data loss. If the same account fails again within a day, the cause is upstream and no amount of local repair will hold, at which point the sensible move is to reduce how many accounts this Mac is asked to keep in sync and to pick a front end that names the failing account clearly, such as Caltimate.