Why do I see no available slots when I try to schedule an event?

This article provides an outline of common reasons why you may not be able to see any availability in a user’s calendar.

All-day & multi-day events #

Sometimes, the calendar owner has events that span or repeat over multiple days, blocking off all time slots during this period. It could be that all of the days included in your query are blocked out by one of these events, so no options to select are returned. The user may be unavailable during this period and the events blocking off their availability is expected. In other situations, the user may not have intended to mark themselves as unavailable for the duration of the all-day or multiple-day events (see next section).

Events marked as ‘busy’ when they should be ‘free’ #

The calendar owner may have set events in their calendar as ‘busy’, when they are still available for the duration of the events, such as when creating ‘Working from home’ or ‘Working remotely’ events. In such cases, the user may wish to change the transparency of these events to ‘free’ to ensure their availability remains unaffected by these events. How this can be done within the user’s external calendar will depend on the calendar provider. Events created via our API can be updated to busy (opaque) or free (transparent) by utilising the transparency parameter.

Availability rules #

If the user’s availability rules were taken into account (see Managed Availability), there may be small or no overlap between the availability rules and the queried periods, resulting in no available slots. You can either adjust the periods you’re checking their availability for, or the user’s Availability Rules can be updated.

Querying multiple calendars or participants #

If you only include the participants.members.sub within the availability request, all user calendars within the calendar profile will contribute to the user’s availability. If there are events within these calendars covering all queried times, no available slots will be returned. Instead, you can specify the only calendar(s) that should be taken into account by utilising the participants.members.calendar_ids parameter. Including multiple participants.members can also cause the availability request to return to available slots. Again, you can restrict the queried calendars by specifying the calendar_ids for each member.

Long event duration with no start_interval specified #

For example, an event’s required duration is set to 60 minutes and no start_interval is specified. If a start_interval isn’t specified, it will match the required_duration by default, meaning that 60 minute slots will begin on the hour. If the user’s calendar has an hour-long meeting at 9:30 and another one at 11:30, no slots will be offered between 9:00 and 13:00, despite the one hour gap between the end of the first meeting and the start of the second. To help with this, you can specify a start_interval of 5, 10, 15, 20, or 30 minutes to allow the availability request to cater for events starting the respective minutes after the hour. Additionally, you can specify a response_format of overlapping_slots.

Event buffers #

Buffers can limit the number of available slots. For example, if a 60-minute required duration is specified and the start_interval is not set, events default to starting on the hour. To accommodate a 10-minute buffer, events could only run from 11:00 to 12:00, then 13:00 to 14:00, and so on. This is because the 10-minute buffer pushes the end time to 12:10, which prevents another event from starting. By specifying a start interval of 10 minutes, events can include the 10-minute buffer. Additionally, setting the response_format to overlapping_slots will display all possible slots that fit within these criteria.

If none of these reasons are relevant in your situation or you’d like further clarification, please email support@cronofy.com and we’ll be happy to help!