Reliability
Something with write access to your calendar has to say how it fails, not only how it works. This is what BusyWait commits to when a calendar sync fails, and what is left in your diary if it ever stops running.
Commitments
If a connection stops and will not recover by itself, BusyWait marks it as needing attention and emails you, naming the calendar. There are no reassurance emails, so a message from BusyWait means something wants you.
A change that cannot be written is tried again, not discarded. If it still cannot be written, BusyWait stops writing to that calendar and says so, instead of syncing part of it and saying nothing.
BusyWait changes and removes the blocks it created and nothing else. An event you created is not altered or deleted, in normal running or in a failure, and a failure does not make a sync carry more than you set it to carry.
Honestly
If BusyWait is behind, your calendars are behind with it. Something booked straight into one calendar in that gap can clash with something booked in another, and BusyWait cannot un-book it. Blocks it has already written are ordinary events, so a stale one can sit in your diary until the next sync clears it.
When someone confirms, the slot is checked again against the calendars selected for that link. Something added to a calendar moments earlier may not have reached BusyWait yet, so a clash is unlikely, not impossible.
How the service itself is secured is set out in the Security Policy.
The long term
It is a small product from a small company, and this is what that means.
The free plan keeps two calendars in sync both ways and is not time-limited. The best evidence for any of the above is a few weeks of not having to think about it.