Share via

Application.OnTime delay increases rapidly when using GetObject across multiple Excel instances (Excel 2024/M365)

OU 20 Reputation points
2026-04-17T10:57:15.8833333+00:00

In Excel 2024 / Microsoft 365, Application.OnTime loses timing accuracy over time when a second Excel instance uses GetObject to communicate with the first. This works perfectly fine in Excel 2010 with no delay accumulation. The delay between scheduled EarliestTime and actual execution grows dramatically within minutes in newer versions.

Test Environment:

Excel: Microsoft 365 / Excel 2024 (issue) vs Excel 2010 (works fine)

OS: Windows 11

Recursive Application.OnTime every 1 second

Response Excel Instance Code (Receiver - Primary):

Option Explicit
Public NextRunTime As Date
Private Const INTERVAL_S As Long = 1
Sub Tick()
NextRunTime = Now + TimeSerial(0, 0, INTERVAL_S)
Application.OnTime NextRunTime, "PrintTick", , True
End Sub
Sub PrintTick()
' Log the actual run time and calculate lag
Dim ActualTime As Date
ActualTime = Now
Dim lRow As Long
lRow = ThisWorkbook.Sheets(1).Cells(Rows.Count, "A").End(xlUp).Row + 1
ThisWorkbook.Sheets(1).Cells(lRow, 1).Value = NextRunTime
ThisWorkbook.Sheets(1).Cells(lRow, 2).Value = ActualTime
ThisWorkbook.Sheets(1).Cells(lRow, 3).Value = (ActualTime - NextRunTime) * 86400 ' Delay in Seconds

Trigger Excel Instance Code (Transmitter - Secondary):

Option Explicit
Sub RunTransmitter()
vba
Dim ReceiverApp As Excel.Application
Dim TargetWbk As Excel.Workbook
Dim fName As String
Dim i As Long
fName = "G:\Response.xlsb" ' *** ADJUST THIS PATH ***
' Get the running instance of the Receiver workbook
Set TargetWbk = GetObject(fName)
Set ReceiverApp = TargetWbk.Application
For i = 1 To 10 ' Run for 10 iterations (5 minutes)
    ReceiverApp.Run TargetWbk.Name & "!Tick"
    Application.Wait Now + TimeValue("00:00:30")
Next i
MsgBox "Transmitter finished running. Check Receiver.xlsb for delay."
End Sub

Steps to Reproduce:

Open Response.xlsb with Receiver code above. Run Tick() to start the 1-second timer

Open Trigger Excel with Transmitter code above. Run RunTransmitter()

Monitor Column C in Response.xlsb Sheet1 for growing delay values

Expected Behavior (Excel 2010):

Column C shows delays ≈ 0 seconds consistently throughout execution.

Actual Behavior (Excel 2024/M365) - Real Data from Column C:

Row | Scheduled | Actual | Delay (seconds)

----|-----------|----------|----------------

1 | 17:00:00 | 17:00:00 | 0

2 | 17:00:01 | 17:00:01 | 0

3 | 17:00:02 | 17:00:05 | 3

4 | 17:00:03 | 17:00:22 | 19

5 | 17:00:04 | 17:00:22 | 18

6 | 17:00:05 | 17:00:24 | 19

7 | 17:00:06 | 17:00:25 | 19

8 | 17:00:07 | 17:00:26 | 19

9 | 17:00:08 | 17:00:27 | 19

10 | 17:00:09 | 17:00:27 | 18

Key pattern: Delay jumps from 0s → 3s → 18-19s within 10 iterations, then stabilizes at 18-19s consistently.

Key Observations:

✅ Excel 2010: Works perfectly, no delay accumulation

❌ Excel 2024/M365: Delay spikes to 18-19 seconds and locks in

  • Schedule:=True parameter doesn't prevent the issue

No workaround found. Excel restart required.

Microsoft 365 and Office | Development | Other

Answer accepted by question author

  1. Gabriel-N 16,565 Reputation points Microsoft External Staff Moderator
    2026-04-17T12:38:32.1133333+00:00

    Hello OU, thank you for the detailed information.

    I did some research and found a thread that appears to show similar behavior to what you are experiencing: Application.OnTime Delays When There Is No User Interaction (Even if Excel Is Active)

    Important: This link will take you to stackoverflow.com , which is outside Microsoft’s domain. Please note that Microsoft is not responsible for the accuracy, security, or advertising on external sites.

    In that discussion, one suggestion was to avoid relying on Application.OnTime and instead use a timer mechanism based on a triggered event that fires every second. This approach got some vote up, so you may want to try it as well and see whether it reduces the delay in your scenario.

    Additionally, as noted in that thread, Application.OnTime in Excel does not guarantee millisecond‑accurate execution. The scheduled execution time is approximate and can deviate by several seconds depending on factors such as Excel’s internal state, automation activity, and user interaction. Based on a number of reported cases, including yours, this observation seems to be valid.

    Regarding the situation where the same Windows 11 environment works fine with Excel 2010 but shows delays in Microsoft 365 / Excel 2024, the thread above also shares some relevant test results. The user observed delays on multiple Windows 11 systems (23H2 and 24H2), while older or upgraded environments behaved differently.

    From these reports, I personally tend to suspect that this behavior is related to changes in the internal architecture and automation or execution model of newer Excel versions. Unfortunately, Microsoft does not publicly document Excel’s internal implementation details, so I don’t have solid technical evidence to explain the exact root cause, this is only my own interpretation based on available reports.

    In summary, I recommend taking a look at the suggested alternative approach mentioned in the thread and testing whether it improves the behavior in your case. I hope this information is helpful.

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    1 person found this answer helpful.
    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-04-17T10:57:32.82+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    This behavior is consistent with known limitations and side effects of Excel Automation and cross-process control, especially when multiple instances and GetObject/Run are involved.

    Key points from the scenario and context:

    1. Excel Automation references can be held implicitly
      • When Automation is used to control Excel, any unqualified calls to Excel objects, methods, or properties can cause Visual Basic to establish its own hidden reference to Excel.
      • These references are not released until the program ends and can interfere with Automation code when it is run multiple times.
      • This is documented as causing errors and unexpected behavior when Automation code is run repeatedly, and the behavior is “by design.”
      • In a multi-instance scenario with GetObject and repeated Application.Run calls, this kind of implicit reference and cross-instance interaction can manifest as timing drift, blocked message loops, and delayed execution of Application.OnTime callbacks.
    2. Server-side / cross-process Automation is fragile
      • Microsoft documents that Automation of Office across processes (for example, server-side or stress scenarios) can lead to:
        • Functions failing unexpectedly or stopping indefinitely because of user alerts or dialogs.
        • Code failing, stopping, or crashing when multiple requests or stress testing are involved.
        • Instances being left running in memory or becoming unstable.
      • The described pattern (delay rapidly increasing and then stabilizing at a high value until Excel is restarted) is consistent with an Excel instance that has become internally blocked or throttled due to cross-process Automation and accumulated state.
    3. Application.OnTime itself is not guaranteed real-time accuracy
      • Application.OnTime schedules a procedure to run when Excel is in a state where it can process events (Ready mode, message loop free, no blocking code or modal UI).
      • If the application is busy (for example, handling cross-instance Automation calls, waiting on COM marshaling, or processing other work), execution of the scheduled macro is delayed until Excel returns to Ready mode.
      • In a single-instance scenario with minimal external Automation, the delay is small; when another instance repeatedly calls GetObject and Run, the primary instance can spend significant time servicing those calls, which pushes out the effective execution time of OnTime.

    Given the available information, this is not a documented bug with Application.OnTime itself but a side effect of:

    • Multi-instance Excel Automation via GetObject and Application.Run.
    • Known limitations and design behavior of Office Automation in multi-session / multi-process or server-like scenarios.

    Practical guidance based on the documented behavior:

    1. Avoid or minimize cross-instance Automation
      • Run both the “receiver” and “transmitter” logic in the same Excel instance if possible, so that Application.OnTime is not competing with cross-process COM calls.
    2. Ensure all Excel object usage is fully qualified
      • In Automation code, qualify every call to Excel objects, methods, and properties with the correct Application/Workbook/Worksheet variables to avoid hidden references that persist and interfere with subsequent runs.
    3. Do not rely on Application.OnTime for strict 1-second timing under Automation load
      • OnTime is designed for scheduling within Excel’s normal UI/event loop, not as a real-time timer under heavy Automation or multi-instance COM traffic.
    4. If the instance becomes “locked” into a high delay state
      • This matches documented patterns where Automation references and cross-process calls leave the Office application in a degraded or unstable state until it is restarted. Restarting Excel is the expected recovery in such cases.

    Because the timing drift arises from these underlying Automation behaviors, there is no supported setting or flag to “fix” OnTime accuracy in this multi-instance GetObject scenario; the supported mitigation is to change the architecture (single instance, reduced cross-process Automation, fully qualified object usage) rather than relying on OnTime as a precise timer across instances.

    References:

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.