Email when a connection needs you
Sent when a calendar has stopped syncing and will not recover by itself — an expired token, a revoked permission, a CalDAV server that has moved. Not sent for a retry that succeeded.
Reliability
What happens when it breaks
Something with write access to your calendar has to say how it fails, not only how it works. This is the failure behaviour in full: what BusyWait retries, what it refuses to guess at, how you hear about it, and what is left in your diary if it stops running.
Speed
What “within seconds” means
Each provider tells BusyWait when something in a connected calendar has changed, and the mirrored block is written on the back of that notification. In normal conditions that is a few seconds end to end. It is a typical figure rather than a guarantee, and it depends on a provider we do not control choosing to tell us promptly.
So notifications are the fast path, not the only path. A sweep runs behind them, comparing both sides of every sync and correcting whatever a missed notification left behind. When the fast path fails you lose the seconds, not the sync.
Change-driven
BusyWait acts when a provider says something moved, rather than sweeping every calendar on a timer and hoping the timer is short enough.
Swept as a backstop
A reconciliation pass compares both sides of each sync, so a dropped notification costs latency rather than correctness.
Idempotent writes
Every mirrored block carries an opaque ID tying it to its original. A retry updates that block; it never leaves a second copy behind.
Failure modes
Every way this goes wrong, and what follows
Six situations, what BusyWait does about each, and what you see while it happens.
| Situation | What BusyWait does | What you see |
|---|---|---|
| A provider is slow, rate-limiting or returning errors | The change is queued and retried with a widening gap between attempts. Nothing is dropped and nothing is written twice. | Sync runs behind for as long as the provider is unhappy. Blocks already written are untouched. |
| A change notification never arrives | Notifications are the fast path, not the only one. A periodic sweep compares both sides of every sync and writes whatever the notification missed. | The gap closes on its own, without you reconnecting anything. |
| An access token expires or is revoked | One retry, in case it was transient, then BusyWait stops writing to that calendar rather than guessing. It does not half-sync and say nothing. | The connection is marked as needing attention and you get an email. Reconnecting takes about as long as it did the first time. |
| You revoke access at the provider | Writing stops at once. Blocks BusyWait has already created stay where they are, because they are ordinary events in your calendar. | Nothing disappears from your diary without you asking. Removing the blocks it created is one action on the connection screen. |
| BusyWait itself is down | Nothing is written while it is down. Provider changes are re-read and reconciled when it comes back. | Your calendars carry on working normally. They just stop learning about each other until it returns. |
| A sync is paused or deleted | You choose whether the blocks that sync created are removed or left in place. Events you created yourself are never candidates for either. | A clean exit, on your terms, from the connection screen. |
The floor
What an outage cannot do
Not promises about how carefully it is run. These hold because of how narrowly the writes are scoped in the first place.
- Change or delete an event you created. BusyWait only ever touches blocks it wrote itself, matched on its own opaque ID.
- Carry more than the sync was set to carry. A failure cannot widen a payload — a retry sends the same three fields the first attempt did.
- Show one client something about another. Each sync is a separate connection, and a failure in one is invisible to the rest.
- Quietly double-book you through a booking link. Availability is re-checked against every connected calendar at the moment someone confirms, not only when the page loaded.
Honestly
What this does not protect you from
If BusyWait is behind, your calendars are behind with it. Someone with write access to one of them can put a meeting in during that window, and if a slot at the same time is confirmed through a booking link in the same window, the clash is real. The sweep surfaces it afterwards. It cannot un-book it.
Blocks BusyWait has already written are ordinary events, which is what makes them survive an outage — and also means a stale one can sit in your diary looking like a commitment until the sweep catches up. That direction makes you look busier than you are, which is the failure worth having of the two.
There is no public status page yet. Today the honest signals are the last-synced time against each calendar and an email when a connection needs you. When there is a status page it will be linked from here.
How the service itself is secured — encryption, access control, and how to report a vulnerability — is set out in the Security policy.
Telling you
How you find out, without watching for it
A sync tool that breaks quietly is worse than one that was never there, because you have stopped checking.
A last-synced time per calendar
Every connected calendar shows when it last completed a sync. A number that has stopped moving is the first thing to check, and you can check it without contacting anybody.
No reassurance mail
There are no "everything is running normally" emails. A message from BusyWait means something wants your attention, which is the only way an alert stays worth reading.
The long term
If BusyWait is ever wound down
It is a small product from a small company, and the fair thing is to say what that means rather than let the confident tone of the rest of the site imply otherwise.
- Sixty days’ notice by email before syncing stops. Not a switch thrown on a Friday.
- Export stays available for the whole notice period — your syncs, your settings and your bookings, in a format you can read.
- Blocks already written stay in your calendars. They are ordinary events, and nobody has to be running anything for them to remain.
- A documented way to remove every block BusyWait created, which keeps working after the accounts do not.
- No sale of the user base as an asset. If the product cannot continue, it ends rather than changing hands.
FAQ
Reliability questions
- How fast does BusyWait actually sync?
- Within seconds in normal conditions. BusyWait listens for change notifications from each calendar provider rather than sweeping calendars on a timer, so a booking is mirrored on the back of that notification rather than at the next polling interval. It is a typical figure rather than a guarantee, because it depends on the provider sending the notification promptly. A periodic reconciliation sweep runs behind the notifications and corrects anything they missed, so a dropped notification costs latency rather than correctness.
- What happens if a sync breaks or a calendar token expires?
- BusyWait retries once in case the failure was transient, then stops writing to that calendar rather than guessing at a half-broken state. The connection is marked as needing attention and you get an email describing which calendar it is and what to do. Blocks already written to your calendars are left exactly as they are — they are ordinary calendar events, so they survive whether or not BusyWait is running. Reconnecting takes about as long as connecting did the first time.
- Does BusyWait have a status page?
- Not yet. Today the signals are a last-synced time shown against every connected calendar, which you can check yourself at any point, and an email whenever a connection has stopped and will not recover on its own. There are no "everything is fine" emails. A public status page is planned and will be linked from busywait.ai/reliability when it exists.
- Can a BusyWait outage or bug delete my calendar events?
- No. BusyWait only ever modifies or removes blocks it created itself, matched on an opaque ID it stores against each one. An event you created is never a candidate for either, in normal running or in a failure. During an outage nothing at all is written; your calendars carry on working and simply stop learning about each other until the service returns, at which point the reconciliation sweep catches up.
- Can a failure leak more of my event data than usual?
- No. A retry sends the same fields the first attempt did — by default a start time, an end time and the status busy. There is no fallback path that widens a payload, no error mode that copies a title, and no diagnostic that ships event contents. If a sync is set to busy-only, every attempt at that sync is busy-only, including the failed ones.
- What happens to my data if BusyWait shuts down?
- You get sixty days’ notice by email before syncing stops, with export of your syncs, settings and bookings available for the whole of that period. Blocks already written stay in your calendars, because they are ordinary events that need nothing running to remain, and a documented way to remove all of them keeps working afterwards. The user base is not for sale as an asset: if the product cannot continue, it ends rather than changing hands.
Connect two calendars and watch it do nothing
Free for two calendars, for as long as you like. The best evidence for any of the above is a few weeks of not having to think about it.