"No available users" message despite slot available
Issue Summary
An error "No available users" occurs despite the slot being available and already selected.
English text:
Could not book the meeting. No available users found. Could you try another time slot?
Steps to Reproduce
- Find a free slot in the calendar (red arrow).
- Check that the time is a free slot (red arrow).
- Fill out.
- Error (see picture).
Error does not occur always, maybe 50% of conversions fails.
Agenda linked through ICS with Proton Calendar.
Expectation: meeting can be confirmed.
Technical details
- Google Chrome, last production version.
- Cal.com Teams Plan
See also
This does not concern a recurring event, just a one off, so https://github.com/calcom/cal.com/issues/18072 might not apply.
Issue has already been reported through chat some time ago. Allegedly work is in progress for this.
Do you have a link to follow on that work in progress? I have the exact same use case and issue.
No, there is no link. All communication took place through chat. This ticket was created to ease tracking.
Thanks for reporting this, I tried reproducing the issue multiple times but couldn't replicate it. Since it happens intermittently, could you share more details? For example, does it occur with specific time slots or users? Let me know, and I’d be happy to dig deeper
It can be reproduced as follows:
- go to https://go.invantive.com/book/introduction
- currently there is a slot free on April 21 14:00
- choose that one
- enter some test data
- book
- "Could not book the meeting"
See picture.
The proton calendar displays (GMT+2):
The ICS source (credentials removed):
https://calendar.proton.me/api/calendar/v1/url/...==/calendar.ics?CacheKey=...%3D%3D
The ICS contains for the meeting of 12:00-14:00:
BEGIN:VEVENT
UID:[email protected]
DTSTAMP:20250401T152555Z
DTSTART;TZID=Europe/Amsterdam:20250314T120000
DTEND;TZID=Europe/Amsterdam:20250314T140000
RRULE:FREQ=DAILY
EXDATE;TZID=Europe/Amsterdam:20250414T120000
EXDATE;TZID=Europe/Amsterdam:20250424T120000
EXDATE;TZID=Europe/Amsterdam:20250425T120000
EXDATE;TZID=Europe/Amsterdam:20250428T120000
SEQUENCE:1
SUMMARY:Busy
EXDATE;TZID=Europe/Amsterdam:20250414T120000
EXDATE;TZID=Europe/Amsterdam:20250424T120000
EXDATE;TZID=Europe/Amsterdam:20250425T120000
EXDATE;TZID=Europe/Amsterdam:20250428T120000
STATUS:CONFIRMED
END:VEVENT
When there is some debugging feature to be activated: will be happy to do so.
@monty241 Thanks for the detailed steps, I visited the page you linked and tried booking the slot, and as expected, it throws the error. However, when testing locally with 22+ manual tests across different scenarios, I couldn't reproduce the issue. Based on the current code, it seems like this issue might have already been fixed. If you still experience this in the next release, feel free to update this thread, and we’ll look into it again
Great! I will retest.
From the bottom of left menu I see current version is v.5.1.14-h-ea7313d with a link to https://github.com/calcom/cal.com/commit/ea7313d7c5109c129adf105c688298c4f13ec744.
What release label should it be in and what is approximate release frequency when everything goes smoothly?
Release Label: Version v.5.1.14-h indicates a minor update or hotfix.
Release Frequency: Minor updates ( v.5.1.x ) are typically released every few weeks, or approximately once a month, when development proceeds smoothly.
- Release Details: Releases
- Future Releases: Milestones
I have the exact same issue, and I still have the issue with the version v5.1.15-h-3b954ba.
What's the version you successfully tested locally?
@ldealmei i was using this: https://github.com/calcom/cal.com/commit/93621baea54f0801fd452c942131a99a1a054690
Then the issue is not fixed because that commit has been deployed in v5.1.12 and we are currently at v5.1.17 and I still get the error. What can we do to help in reproducing the issue?
Retested on v.5.2.7-h-c06cd42. Issue still occurs (user reported it, was able to reproduce).
I'm also seeing this issue. version is v.5.3.4-h-53a0679, on the free plan, using firefox on NixOS. This is the response header:
HTTP/2 409 date: Sat, 24 May 2025 18:54:51 GMT content-type: application/json; charset=utf-8 content-length: 44 cf-ray: 944f00fbc812dd19-ATL cf-cache-status: DYNAMIC cache-control: public, max-age=0, must-revalidate etag: "1ajn3qlfsb18" strict-transport-security: max-age=63072000 vary: Accept-Encoding referrer-policy: no-referrer-when-downgrade x-content-type-options: nosniff x-matched-path: /api/book/event x-vercel-cache: MISS x-vercel-id: iad1:iad1:iad1::cle1::nncsd-1748112890482-88e67730897e server: cloudflare X-Firefox-Spdy: h2
I had multiple proton calendars linked through ICS and booking worked when I removed them.
Hey, I still have this issue, when I "Toggle the calendars you want to check for conflicts to prevent double bookings.", it works, the public link to book an appointment "check for conflicts". BUT
But, it doesn't work, it doesn't book, there is still : "Could not book the meeting. No available users found. Could you try another time slot?"
And then if I disable the "checking for conflicts", it works. But without my personal calendar.
Just to say, if someone take an appointment, it won't be available anymore by the public link to book an appointment. That's a good think.
Check this comment for a workaround until this issue is fixed: https://github.com/calcom/cal.com/issues/23391#issuecomment-3344101044
It seems that it works again. On the online version 5.7.11
I just tried to connect my proton calendar. On the public meeting link, my proton appointment is "checked for conflicts". And when I try to schedule an appointment by the public meeting link, it works :
- It doesn't print "Could not book the meeting. No available users found. Could you try another time slot?"
- And invitations are sent.
Not working for me. Tried just now on v.5.7.11-h-eae2711 (Dutch, but same text):
I added a repo case with a live event here: https://github.com/calcom/cal.com/issues/23391#issuecomment-3636439494
nb. This bug is not just a huge inconvenience, it is causing me reputation damage.
Not a good look at all when a busy client and/or their exec. assistants keep getting "no available users" when the promised time band is clearly open on my cal.com
Dito, we have to call customers churning else. Due to efforts to disentangle with US tech we prefer cal.com as less US tech, but it is costly and makes our customers associate our company with lack of quality / poor decisions. Bug is open for 8+ months.