Testing ends with a written report: what I found, how bad it is, and what I'd do about it. Talking about that is cheap, so here is one instead. I ran a single two-hour exploratory session against Cal.com and wrote it up the way I would hand it to stakeholders. It is reproduced below in full, findings and all.
Nobody hired me to write this.
Cal.com didn't commission it and hasn't reviewed it. I picked a product I actually use, spent two hours on it, and published what I found. An example report is only worth reading if the findings are real ones.
Product
Cal.com· open source, free plan
Session
Two hours· one exploratory session
Findings
Two· plus four minor
Commissioned
No· unsolicited
Diagnostic report
Diagnostic Report: Cal.com
Tested by
Ben Ashton, Ashton Software Testing LLC
Window
August 4th, approximately two hours
Scope
Booking flow, availability computation, and two-way calendar synchronization with Google Calendar and Microsoft Outlook, from the perspective of an individual organizer on a free account.
Out of scope
Team and round-robin scheduling, payment-coupled bookings, the API and webhooks, security, performance and load, mobile applications, self-hosted deployments.
Nobody hired me to do this. I test software for a living, and I wanted to publish an example of what a short diagnostic engagement actually produces, on a real product, with real findings. Cal.com is open source and I use it myself, which made it a natural target.
Summary
Two hours of exploratory testing, focused deliberately on the seams between Cal.com's internal state and the state of a connected external calendar. That is where scheduling software usually breaks, and it is where the two findings worth your attention are.
The finding that matters: Cal.com's calendar sync is described as two-way and behaves as one-way with gaps. Rescheduling from inside Cal.com removes the event from a connected Outlook calendar and never restores it. Changes made on the calendar side, deleting an event in Outlook and declining in Google, do not propagate back to Cal.com at all. Both failures are silent. Neither the organizer nor the attendee has any signal that the two systems have diverged.
The finding that suggests a class of problem: at daylight saving boundaries, the set of bookable slots depends on the viewer's timezone, and slots that cannot actually be booked are still displayed. The commercial impact is small. What it indicates about the availability engine is not.
The rest of what I found was minor. Friction on the manual add-to-calendar path and a stale-until-refreshed booking list. Those are in the appendix.
If this were my product, I would treat the reschedule path as urgent. It destroys an event the user did not ask to remove, which is a worse failure than failing to create one.
Overall read: the core booking mechanics are solid. Availability rules responded correctly to layered constraints, concurrent booking attempts on the same slot were handled cleanly, cross-timezone booking worked, and recurring events survived a DST transition intact. The risk in this product is not in the scheduling logic. It is at the boundary where Cal.com hands off to systems it does not control.
Findings
Finding 01Treat as urgent
Cal.com and external calendars drift apart, silently.
What happens
Intuitively, Cal.com's calendar sync is two-way but only one-way in practice. Most importantly, it fails without telling anyone.
When an organizer requests a reschedule from inside Cal.com, the original event is removed from the connected Outlook calendar and never comes back. Not when the attendee picks a new time, and not on any subsequent sync. The meeting exists in Cal.com. It does not exist on the calendar the organizer actually looks at.
The reverse fails too. Delete the event directly in Outlook, or decline it in Google Calendar, and Cal.com registers nothing. The booking stays active, the slot stays consumed, and the attendee is never told the organizer has effectively dropped the meeting.
Who does it affect?
Any organizer who runs their day from a connected calendar rather than from the Cal.com dashboard. Both paths are ordinary usage, not edge cases: rescheduling is a first-class feature, and declining an invitation is the standard way people say no.
Why does it matter?
An organizer's calendar is their plan for the day. When it disagrees with the booking system, someone doesn't show up and the person who got stood up doesn't blame the software. They blame the business owner who sent them the link. A no-show attributable to a scheduling tool is a support ticket; a no-show attributable to the business is a lost customer and a one-star review. The severity here isn't the frequency of the bug, it's that the failure is silent on both ends. Neither party has any signal that the two systems have diverged until the meeting time passes.
How do I reproduce this?
Direction A: reschedule cancels the meeting
01Connect an Outlook calendar and confirm a booking appears on it.
02In Cal.com, open the booking and select Request reschedule.
03Observe the event disappear from Outlook.
04Complete the reschedule as the attendee.
05The new booking appears in Cal.com. No event returns to Outlook, on completion or after subsequent syncs.
Direction B: calendar changes don't propagate back
01Open a synced booking directly in Outlook and delete it. (In Google Calendar, respond No.)
02Return to Cal.com. The booking remains active and unchanged. The attendee receives no notification.
Tested on Chrome on August 4th. Direction A confirmed on Outlook only.
What would I do?
The reschedule path is what is urgent. It destroys an event the user didn't ask to remove, which is worse than failing to create one. Longer term, the pattern worth addressing is that neither side surfaces divergence at all, even a “this event may be out of sync” indicator would convert a silent failure into a visible one.
Finding 02Not a blocker, a signal
Availability at Daylight Savings Time boundaries depends on who is looking
What happens
At the fall daylight saving transition, the slots Cal.com offers are not consistent, and they are not consistent in a way that depends on the viewer's timezone.
With availability configured across the 1:00–2:00 AM window on the fall-back date, a viewer in a DST-observing timezone sees the hour twice. Which is technically correct, since the hour genuinely occurs twice, though the two instances are not distinguishable in the interface. A viewer in a timezone that does not observe DST, such as America/Phoenix, sees it once.
In both cases, slots are displayed that cannot be booked. After booking the first 1:00 AM instance and refreshing, a 1:00 AM slot still appears in the picker. Selecting it fails.
Who it affects
Directly, only people booking in the small hours on two specific dates a year. That is a narrow population.
Why it matters
The direct commercial impact is low, and I would not prioritize the 1:00 AM case on its own merits.
What makes it worth a page is what it says about the availability computation. Two different viewers are being shown two different answers to the same question, and both are being shown slots that the booking endpoint will reject. That means slot generation and slot validation are not applying the same rules, and that timezone handling in slot generation is not stable across observers.
The 1:00 AM window on one November date is where that becomes visible. It is unlikely to be the only place the underlying inconsistency exists, it is just the place where the arithmetic is unusual enough to expose it. If I were investigating this product further, this is the thread I would pull.
How to reproduce
01Set availability to include 1:00–2:00 AM on Sunday, November 1, 2026.
02Open the public booking link and navigate to that date. In a DST-observing timezone, the 1:00 AM hour appears twice.
03Book the first 1:00 AM slot.
04Refresh the booking link. A 1:00 AM slot is still displayed. Attempting to book it fails.
05Change the viewing timezone to America/Phoenix and repeat. The duplicate slot does not appear, but unbookable slots are still displayed.
Tested on Chrome on August 4th.
What I'd do
Not a release blocker on its own. I would treat it as a diagnostic signal and check whether slot generation and slot validation share a code path. If they do not, that divergence is worth closing regardless of the DST case, because it will produce unbookable-slot bugs in other conditions that are harder to notice.
For the DST window specifically, the honest fix is probably to disambiguate the repeated hour in the interface rather than to hide one instance.
What I didn't get to
Two hours buys a focused look at one area, not coverage. I spent the time on the boundary between Cal.com and external calendars, because that is where I expected the highest-value findings, and I think that was the right call. These are the areas I would target next, roughly in the order I would take them:
Team and round-robin scheduling. Round-robin multiplies the availability problem across several people's calendars, each with independent sync state. Given what Finding 1 shows about single-organizer sync, this is where I would expect the same class of defect to compound. Assignment fairness and what happens when an assigned host's availability changes after a booking are both worth attacking.
Payment-coupled bookings. Where Stripe is connected, the interesting failure is a payment succeeding while the booking does not, or the reverse. Abandoning the payment step mid-flow and inspecting what state the slot is left in is a fifteen-minute test with a large potential finding.
Booking limits and caps in combination. I confirmed individual availability rules behave correctly. I did not systematically test combinations: daily caps interacting with buffers, minimum notice interacting with date overrides, or how a cap counts a cancelled booking. Rule interactions are where availability engines usually fail, not individual rules.
API- and webhook-created bookings. Everything I tested went through the web interface. Bookings created through the API may not traverse the same validation path, which is worth confirming rather than assuming.
Recurring series where availability changes mid-series. Recurring events survived a DST transition cleanly. I did not test what happens when the organizer edits their availability underneath an active series.
How I tested
I did some exploratory testing for two hours focused on internal state and External Calendar integration.
I concentrated on the integration with external calendars, timezone conversion, and concurrent access. I chose these because scheduling software is generally competent at its own arithmetic and generally weaker where it has to stay in agreement with something external. Both findings came out of that area, which is some evidence the choice was right.
Setup: an account with Google Calendar and Microsoft Outlook connected, on a free plan. Testing was ordinary user activity in a browser. Configuring availability, booking, rescheduling, cancelling, and modifying events on the calendar side. No automated tooling, no API access, no attempt to reach data belonging to anyone else.
Things I confirmed working, which are worth stating because they narrow where the risk actually lives: layered availability rules behaved correctly, including same-day booking controls and existing-event conflicts; two simultaneous booking attempts on the same slot were resolved cleanly with one accepted and one rejected; cross-timezone booking worked; all-day events on Google Calendar correctly cleared availability; spring-forward correctly skipped the 2:00–3:00 AM window; and a recurring meeting booked across a DST boundary held its intended time.
Appendix: minor observations
·
Add to calendar → Microsoft Outlook routes to the Microsoft 365 store page rather than adding the event. Signing in with a custom-domain address lands in the inbox with no event added. Works as expected for a native Outlook address. Low impact. The user sees the failure immediately and can add the event manually.
·
“Microsoft Office” as an add-to-calendar destination is not a meaningful category alongside “Microsoft Outlook,” and it is not clear which one a user should choose.
·
The upcoming bookings list is stale after a reschedule until the page is refreshed. Attempting a second reschedule from the stale view produces an error rather than a refresh.
·
An open booking link does not react to availability changes made while it is open. Booking a now-unavailable slot fails with an appropriate error message, so the outcome is correct; the interface is simply behind.
Ben Ashton is a software quality engineer in St. George, Utah, working in test strategy, API automation, and context-driven testing. benashton.dev
Next step
That was two hours. Imagine it on your product.
I'm looking for a senior or lead QA role. My resume has the rest of the story.