Extremely slow availability appearance on round robin with large pool of event hosts

4 replies
121 views

We have a group of about 40 calendars where a round robin event has to grab availability and who’s next to get an intro meeting with a person using our experience.

As soon as the person views the monthly calendar, it takes 20-30 seconds to load availability. If they go to the next month, it again takes 20-30 seconds to load the calendar.

We’re tied to Outlook calendars and I imagine that is the reason for the extreme slowness. Are there ways to configure Calendly or our integration with Outlook to speed this up?

David

Community Manager

Hi @kempj48 - Thank you for raising this!

Our team is aware of the issue and we’re looking into it. We were able to determine that any reduction in the total number of elements (Event Types, Teams, Users, being used by your organization could potentially improve the performance.

Totally understand that there may be a lot of events that are necessary, but if there happen to be any duplicates or extra items that you no longer need, this could be a good time to clear those out.

Let me know if you have any questions!

K

kempj48Author

Community Member

Yeah, the reduction of elements doesn’t feel like the right solution since we don’t have a crazy number of any of these elements imho. Routing is likely not the silver bullet here either after we considered it.

We’d like to understand what your engineering group has found so we can distinguish if it’s a temporary thing or if there will be a more permanent fix.

Could you clarify these to help us understand:

Has engineering identified where most of the time is spent, such as calendar retrieval, Round Robin aggregation, slot calculation, or caching? To me, the “range?timezone=….” calls are breaking out each week of the month with each taking many seconds. Even when I jump back to a calendar month that has already been loaded once, the 304 responses, seem to take 70% of that 30 seconds that the very first 4-part request takes (200 responses).
Can one slow or unhealthy host/calendar connection delay the entire Round Robin availability response?
Does GET /event_type_available_times use the same underlying availability calculation as the hosted widget?
Is there any supported event or telemetry for “availability ready” / “slots loaded” in the embedded scheduler?

K

kempj48Author

Community Member

saw a response email come through from someone...but cannot seem to see it here. It said...

“With 40 calendars, the bottleneck is likely the availability aggregation across Outlook rather than the UI itself. I’d check whether Calendly is querying all calendars for every month view and reduce unnecessary calendars or routing rules where possible. Caching availability or narrowing the scheduling window can also significantly reduce repeated Outlook API calls."

would be super helpful to know if there is a way from Calendly admin UI for me to have our admin be able to toggle something to configure how we query calendars (daily, weekly, monthly) and progressively build out the availability rather than waiting for the all the calls to finish. it just sat like this for roughly 2 mins when i just did it a bit ago.

after digging more, it’s more like 30 calendars. also, confirmed we are only getting 3 weeks’ worth for our window.

in any case, more fine-grained control on how a customer configures this or some guidance on how to tell the calendar to load it as it gets it (there’s probably a fancy term for this) would be amazing.

thanks all for any consideration and assistance!

T

tsafadi

New Community Member

Hello,

Calendly has become super slow. It’s at a point where we have to change to a different provider. We reduced it to only 2 hosts but even then, we still have loading times of 10 seconds. We embedded it via inline widget but this also happens on the Calendly site.

Observed behaviour (14 Oct 2026, around 14:30–15:15 CEST)

Inline embed: the iframe is inserted within about 30 ms of page load. Calendly immediately posts calendly.page_height = 26px (loading state). The rendered calendar (calendly.event_type_viewed, page_height = 700px) only arrived after:
- Run 1: about 9.9 s
- Run 2: about 18.1 s (page_height 26px at 1.1 s → 2px at 17.0 s → event_type_viewed and 700px at 18.1 s)
Direct booking page (no embed):
- Run A: calendar visible after about 7.0 s
- Run B: page stalled; after 9 s only initial_settings had been requested, and no further API calls followed
- Run C (after reducing to one host and a 30-day window): calendar complete after about 8.8 s
Our own page is not the bottleneck: TTFB about 5 ms, DOMContentLoaded about 60 ms, load event about 760 ms.

Request waterfall, direct page, run C (start time / duration / server wait, which is time to first byte)

Request	Start	Duration	TTFB
/api/booking/initial_settings	719 ms	243 ms	241 ms
/api/booking/scheduling_links/cvgj-nsn-pb4	1017 ms	359 ms	288 ms
/api/booking/event_types/lookup	1405 ms	1154 ms	1151 ms
/api/booking/features/69c110de-357f-4575-88f5-53a460391698	2814 ms	543 ms	540 ms
/api/booking/experiments	2814 ms	697 ms	694 ms
/api/booking/event_types/be98dab3-…/calendar/range	3945 ms	2411 ms	2387 ms
/api/booking/event_types/be98dab3-…/calendar/range	6366 ms	2463 ms	2461 ms

In run A, event_types/lookup took 3104 ms and the two calendar/range calls took 922 ms and 1177 ms.

What we see

Almost all of the time is server-side wait (TTFB ≈ total duration). Download and our network are not the cause.
The requests run strictly one after another: lookup → features/experiments → calendar/range → a second calendar/range.
calendar/range is requested twice in sequence, probably because the 30-day window spans two months. Each call takes about 2.4 s.
Performance varies a lot between loads (7 s to 18 s, plus one complete stall).

Sign up

Not a Calendly user yet? Head on over to Calendly.com to get started before logging into the community.

Login to the community

Not a Calendly user yet? Head on over to Calendly.com to get started before logging into the community.