It was 4:51 PM on a Friday. The script had been running for two days. My phone buzzed with a push notification: a 12:30 PM Cake Bake Shop slot, Sunday, Mother's Day. I tapped through to Disney's site, booked it, and the confirmation email landed nine seconds after the alert. Not nine seconds after I started booking. Nine seconds after the notification.
That table had been gone for weeks. We had given up on it. The only reason we got it is that something was checking every minute and told me the instant it appeared. By the time I would have thought to refresh the app myself, it would already have been taken.
The catch is documented in its own post. This one is about the log file. Two days, 2,395 entries, and a lot of time to watch how Disney availability actually behaves. Here is what it showed.
Methodology caveats
This is a single founder case study (N=1), not a fleet benchmark. One restaurant, one date window, one party size, one polling script, one weekend. The 2,395 checks happened over 52 hours, and the catch was at 4:51 PM on a Friday. I booked the slot on Disney's site.
What I learned is specific to that watch. It does not prove how every restaurant behaves, how every date window behaves, or how SpotSitter performs at scale. It is one clean receipt showing that minute-by-minute checking surfaced this particular opening. Do not treat it as a promise of the same result.
Availability is a pulse, not a trickle
The Cake Bake Shop slot did not drift in slowly. One check: nothing. The next check, about a minute later: the slot was there. I booked it. That window stayed open for maybe a few minutes total, and then it was gone again.
That is the most important thing this run showed me: this opening appeared between two checks and did not remain available for long. I cannot infer the cause from the log, and one watch does not establish how all Disney inventory behaves.
Once you see availability as a pulse instead of a trickle, every other decision changes.
The polling interval is the whole game
For this watch, a shorter interval reduced the chance that the opening would appear and disappear between checks. The log does not support a fleet-wide miss rate or a general claim about every restaurant.
I did not appreciate how much the interval could matter until I saw this opening appear between adjacent checks. That observation shaped the product, but it remains an observation from one run.
This is also why manually refreshing the app a few times a day is close to hopeless for the hard reservations. Most people check every four to eight hours. Given how fast availability moves, the odds are not in your favor, no matter how disciplined you are about remembering to look.
The 60-day window is real, but it's half the story
Most Disney dining advice is about the 60-day advance booking window. Wake up at 6 AM, be ready when it opens, get your table. That advice is correct, and for high-demand restaurants you should still follow it.
But my catch happened at 4:51 PM on a Friday, for a Sunday lunch two days out. That is not a booking-window situation. That is a last-minute cancellation from someone who booked ahead and then had plans change.
The log showed one last-minute opening two days before the meal. It did not show why the table became available, so I cannot attribute it to a cancellation or an inventory change.
So if the 60-day window has already passed, you have not missed your only shot. If you are already at Disney or close to your travel dates, high-demand restaurants still open up. It just requires watching near the date, not only at booking time.
The session timeout is a silent killer
Disney's reservation system times out a browser session. Over my 52 hours, it happened once. When it did, the checker stopped working until I logged back in manually.
That is a solvable problem, but it means any real monitoring setup has to manage the session. A simple script that ignores this does not crash with an error. It just quietly stops catching anything while still looking like it is running. You could lose hours of coverage and never know.
I only caught it because the script logged every check and I noticed the count had stalled. Someone running a less transparent setup would have had no signal at all. This is most of why I care so much about a system being honest about whether it is actually working.
What I wish I had known
The most common way people miss last-minute Disney tables is trusting the app to tell them when something opens. It does not. There is no push alert. You have to go back and look, and by the time you do, the pulse has already passed.
The second most common way is running a tool that checks too slowly or silently stops, so it feels like you are covered when you are not.
If there is a reservation that matters to your trip, monitoring can reduce the number of manual checks you make. In this case, the alert brought me to Disney's booking flow while the opening was still available. That is the useful lesson from these 2,395 checks—not a promise that another watch will end the same way.
SpotSitter is independent and not affiliated with The Walt Disney Company or Disney Parks. We do not store your Disney credentials. Ever.
Set a watch on the table you actually want.
Your first watch is free. One watch, push and email alerts, checks every 120 seconds. No card, no trial clock.
We watch the page. You enjoy the trip.