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

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