Subject: Microsoft Graph Excel API – Workbook Operations Timing Out on Small Files

Question

Hi Microsoft Support Team,

We are experiencing consistent timeout errors when making Microsoft Graph API calls to Excel workbooks hosted on SharePoint Online. The issue occurs even on relatively small files (~8.6 MB) with 27 rows of data.

What we observe:

• Calls to /workbook/worksheets, /workbook/tables, and /workbook/worksheets/{id}/usedRange all time out
• The file in question has minimal data (27 rows, ~13 columns)
• The issue is reproducible across multiple requests and multiple files on the same SharePoint site

Suspected root cause: We believe each API call is triggering a full cold-open of the workbook server-side, as we are not using persistent workbook sessions (Workbook-Session-Id). For workbooks with multiple sheets, formulas, or conditional formatting, this cold-open appears to exceed the server-side timeout even when the raw file size is small.

What we've tried:

• Verified the file is accessible and not corrupted
• Confirmed our access token and permissions are valid (Files.Read.All, Sites.Read.All)
• Retried at different times — same result

Questions:

1. Is there a known issue with workbook cold-open timeouts on this tenant or region?
2. Is there a recommended file complexity threshold beyond which sessionless calls are expected to fail?
3. Can you confirm whether persistent sessions (createSession) are the intended mitigation for this class of timeout, and if so, is there guidance on session lifetime and limits?

Environment:

• API version: Microsoft Graph v1.0
• Auth: Client credentials (app-only)
• SharePoint region: EMEA
• File: .xlsx, ~8.6 MB, hosted on a SharePoint Online document library

Thank you for your help.

Answer 1

Hi Salah Eddine Gouzi 

In addition to the response provided by the AI, I would like to share some additional insights: 

At the moment, I have not found any official documentation confirming that this behavior is a known issue related to workbook cold‑open timeouts. 

From my research so far, sessionless Excel API calls may be less efficient because the Excel service needs to locate the workbook on the server for each operation. This means that even if the file size is small, the workbook structure or calculation complexity may still impact performance. However, there is no documented threshold that clearly defines when this behavior may occur. 

Reference: Manage sessions and persistence in Excel - Microsoft Graph | Microsoft Learn   

For an official confirmation and more targeted support, I would recommend reaching out to the Microsoft support team using the options available in Microsoft Graph | Support 

I hope this provides some additional direction.

---

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.

Answer 2

1. There is no tenant- or region-specific cold-open timeout issue documented in the provided material. However, Excel workbooks can take an indeterminate amount of time to open or perform operations, and this can cause timeouts when using the regular request pattern.
2. No explicit “file complexity threshold” is documented where sessionless calls are expected to fail. Instead, guidance focuses on:
   • Avoiding very large or unbounded ranges (for example, A:B, C:C) because these can cause large resource utilization and errors.
   • Splitting large range operations into multiple smaller ranges to reduce resource usage and avoid errors.
   • Being aware that workbook complexity (formulas, formatting, number of cells) can significantly affect resource usage and performance, even if the file size is small.
3. Persistent sessions and the long-running operation pattern are the recommended mitigations for operations that may take a long time:
   • Use createSession and pass persistChanges: true to create a persistent session for the workbook. Subsequent calls should include the workbook-session-id header so that the same session is reused.
   • For session creation that may take a long time (for example, opening a complex workbook), use the long-running operation pattern by adding Prefer: respond-async to the createSession request. This returns 202 Accepted with a Location header to poll for status (notStarted, running, succeeded, failed). Once succeeded, retrieve the session creation result from the provided URL.
   • Persistent sessions typically expire after about 5 minutes of inactivity; non-persistent sessions expire after about 7 minutes of inactivity. To avoid session expiration during a series of operations, either:
     • Keep the session active with periodic requests, or
     • Detect 404 on sessionful requests and create a new session.

Additional operational guidance relevant to timeouts and reliability:

• Throttling and Retry-After:
  • Excel APIs are subject to throttling based on resource usage. When throttled, responses may include a Retry-After header. No follow-up requests should be sent before the specified cooldown duration.
  • Excel has service-specific limits such as 5000 requests per 10 seconds per app (all tenants) and 1500 requests per 10 seconds per app per tenant.
  • To reduce throttling and related failures, avoid high concurrency against the same workbook. For each workbook, send the next request only after receiving a successful response to the current request, especially for write operations.
• Error handling:
  • For timeouts or other failures, follow the documented error-handling steps: parse second-level error codes when present, then top-level error codes, then HTTP status codes, and respect any Retry-After headers.
  • For sessionful requests that encounter 502 or 503 without a known second-level error code, recreate the session.

Putting this together for the described scenario:

• Use createSession with persistChanges: true and Prefer: respond-async for complex workbooks to avoid cold-open timeouts.
• Reuse the returned workbook-session-id for all subsequent /workbook/worksheets, /workbook/tables, and /workbook/worksheets/{id}/usedRange calls.
• Keep requests sequential per workbook and avoid unbounded or very large ranges; if needed, split large reads/writes into smaller ranges.
• Handle throttling and errors according to the Retry-After header and error-handling guidance.

---

References:

• Best practices for working with the Excel API
• Working with Excel in Microsoft Graph
• Error handling for Excel APIs
• Microsoft Graph service-specific throttling limits