What happens when the bot's 'join_at' is in the Past?

Last updated: March 27, 2025

The join_at time allows you to schedule a bot for a future time, but can be confusing when it's set for a time in the past. The following article explains this behavior.

What happens when a bot is scheduled for a time in the past?

When you schedule a bot with a 'join_at' time that has already passed, our system provides an ad-hoc bot on-demand at the time of the request. For example:

  • You request a bot at 12:15 UTC

  • You set the join_at to 12:00 UTC (15 minutes in the past)

  • The bot will start joining the call immediately at 12:15 UTC

  • The joining_call event will show 12:15 UTC

  • The join_at value on the bot will still show 12:00 UTC

Thus, a discrepancy between the bot's join_at time and joining_call time does not mean that a bot was late, but that the join_at time was in the past.

Ignore the ready event

You might wonder why the timestamp of the ready event can vary so much in relation to the joining_call. This is due to how Recall.ai's infrastructure works internally, and you should ignore this status code since it's not directly related to when a bot starts joining a call.

Best practices for scheduling bots

Our system allows scheduling bots for past times and provides an ad-hoc bot instead of returning an error. This flexibility is useful for certain scenarios, but may lead to confusion when debugging join times.

To avoid any confusion around bot join times, you can:

  1. Check if the current time is past the value you're setting for join_at

  2. If the join_at is in the past, simply omit the time to provide an ad-hoc bot immediately.

  3. Consider having a threshold where a bot is not scheduled at all (for instance, if the join_at is several days in the past, it's unlikely that the meeting is still occurring and this could point to a bug in your code.