Hi Raja,
Yes, this is expected behavior.

A Mendix Scheduled Event can execute only while the Mendix Runtime/application is running. If the server is down at the configured execution time, the event cannot execute at that exact time.

When the server/application starts again, the scheduler evaluates the scheduled event and may execute a missed occurrence. Therefore, if the server has been offline over a period where multiple executions were missed, you may see the event execute more than once after startup, depending on the Scheduled Event configuration and scheduler behavior.

So in your example:

• Scheduled time: 1:00 AM
• Server down: 11:00 PM – 9:00 AM
• Server starts: 9:00 AM
• The event cannot run at 1:00 AM because the Runtime was unavailable.
• After startup, the scheduler can process the missed execution.

For the weekend scenario, if the event is scheduled at a frequency that results in multiple missed executions while the server is offline, this can explain why you observe multiple executions when the server comes back online.

It is also worth checking the Scheduled Event's Start time, recurrence/frequency, and Enabled setting, as these determine how the scheduler handles the event.

Kindly mark this as the accepted answer if it helps.

Hi,

Since your app is on Mendix 10.24.3, your scheduled events run on the Task Queue. Legacy scheduled events are deprecated and will no longer be supported from Mendix 10. That explains both behaviours. mendix

1. Will the 1:00 AM event run when the server comes back at 9:00 AM?

Yes, this is expected in Mendix 10. The next run of a scheduled event is stored in the database as a queued task (System.QueuedTask) with a planned start time.

At 1:00 AM no runtime is running, so the task stays in the database as overdue. When the server starts at 9:00 AM, the runtime finds the overdue task and runs it immediately. It then schedules the next run for 1:00 AM the following night.

It only catches up once. It does not run once for every missed occurrence.

If you don't want this catch-up run, add a check at the start of the microflow. For example, only continue if the current time is within an expected window such as 00:55–02:00, or if today's run hasn't been done yet.

2. Why does it run twice after the weekend?

This is most likely a known runtime issue that was fixed in a later 10.24 patch, after your version. The Studio Pro 10.24 release notes say the following.

In 10.24.17:

• We fixed an issue where synchronization would cause a scheduled event to be executed multiple times. mendix
  
  
• We now cleanup pending MendixRuntime-UpdateScheduledEvent and MendixRuntime-DeleteScheduledEvent system tasks before synchronizing scheduled events. mendix
  
  

In 10.24.13:

• We fixed an issue where scheduled events with On overlap configured as Delay next would cause multiple "Skipping the update of ScheduledEvent because it's running; retrying in 7 seconds." log messages if the application was started with some time between the shutdown and the restart. mendix
  
  

Your situation is exactly this: a restart after a long gap, during which the runtime synchronizes scheduled events at startup. Version 10.24.3 has none of these fixes.

Recommendation: upgrade to the latest 10.24 LTS patch. The current one is 10.24.26. This is a patch upgrade within the same LTS line, so it should be low-risk. mendix

Hi Raja,

Since Mendix 10 scheduled events are executed through the Task Queue mechanism, there are a couple of important details to consider.

For the first scenario, I would not assume that a scheduled event missed while the application is completely down will automatically execute at startup. The at-least-once guarantee applies to tasks that are already in the Task Queue. Mendix does not document this as a general catch-up mechanism for every scheduled execution that was missed while the runtime was unavailable.

So, if the event is configured for 01:00 AM and the application is completely unavailable from 23:00 to 09:00, I would not rely on the 01:00 execution being automatically triggered at 09:00. The next scheduled occurrence will depend on the configured schedule.

For the second scenario, where the application is offline for the weekend and the scheduled event appears to execute twice after startup, I would check the Task Queue logs and System.ProcessedQueueTask records first.

In particular, check:

• The scheduled event name
• Execution/creation timestamps
• Status (Completed, Failed, Retrying, Aborted, etc.)
• Whether the task was already running when the node went down
• Whether the application is running in a clustered setup

An Aborted task is particularly important here. If a cluster node goes down while a Task Queue task is running, Mendix creates a System.ProcessedQueueTask entry with status Aborted, resets the task, and retries it on another node. This is part of the at-least-once execution guarantee, so in a node-failure scenario a task can potentially be executed more than once.

Also check the scheduled event's On overlap setting. Skip next and Delay next can affect execution when one scheduled execution overlaps with the next scheduled occurrence.

I would also verify the UTC/Server time setting, especially if the execution time does not match the expected 01:00 AM.

So, in short:

Server unavailable at scheduled time
        ↓
Do not assume a missed execution is automatically caught up
        ↓
Check the Task Queue / scheduled-event behavior

Whereas:

Task already running
        ↓
Node goes down
        ↓
Task becomes Aborted
        ↓
Task is reset
        ↓
Another node can execute it again

That second case can explain why you may observe an additional execution after a node/application failure.

I would start by checking the System.ProcessedQueueTask entries and Queue log around the weekend restart. That should show whether the second execution was caused by an Aborted/retry scenario or by the scheduled event itself.

References:

• Mendix – Scheduled Events
• Mendix – Task Queue

Hope this helps.