Fixing Microsoft 365 Copilot Agent Timeouts

We recently encountered an unusual issue while building a custom engine agent for Microsoft 365 Copilot and Teams and hosting it in an existing Azure App Service. The agent appeared correctly in Copilot, but every request timed out after approximately 45 seconds.

At first, this looked like an application or authentication problem. The Azure Bot messaging endpoint was correct, Direct Line requests worked, and the application could authenticate and send outbound responses. However, Application Insights showed no request reaching /api/messages.

The request was failing before the Agent Framework application, ASP.NET Core, or Application Insights could observe it.

What Microsoft 365 Copilot requires from the agent endpoint

Before the Agent Framework application can process a message, Microsoft 365 Copilot's agent delivery infrastructure must be able to establish a secure connection to the messaging endpoint through Azure Bot Service. That path has several requirements:

• The Azure Bot messaging endpoint must point to the correct HTTPS URL, including the /api/messages path.
• The hostname must resolve correctly and present a valid, trusted TLS certificate.
• The hosting front end must accept TLS 1.2 connections. It can also support TLS 1.3, but TLS 1.3 cannot be the minimum for this delivery path.
• Network access restrictions, private endpoints, and firewalls must allow Azure Bot Service to reach the endpoint.
• After the connection succeeds, ASP.NET Core must route the request to the Agent Framework application, where authentication and message processing can begin.

These requirements are evaluated in order. Application authentication and Agent Framework diagnostics cannot explain a failure that occurs during DNS, network access, or the TLS handshake.

The symptoms pointed in different directions

Several important pieces were already working:

• The Azure Bot messaging endpoint was configured correctly.
• Direct Line requests reached the application.
• Authentication succeeded.
• The application could send outbound responses.

In Copilot and Teams, though, the user only saw a timeout after approximately 45 seconds. There was no exception in the application and no failed request in Application Insights. There was no request at all.

If /api/messages had been reached and our code had failed, we would expect an HTTP request, status code, exception, or trace. The complete absence of HTTP telemetry meant the failure was earlier in the connection path.

Where the request stopped

A normal request follows this path:

Microsoft 365 Copilot or Teams
  -> Agent delivery infrastructure through Azure Bot Service
      -> TLS handshake with Azure App Service
          -> HTTP POST /api/messages
              -> ASP.NET Core
                -> Agent Framework application
                  -> Application Insights telemetry

In our case, the connection stopped at the TLS handshake. An HTTP request is created only after that handshake succeeds, so the Agent Framework application, ASP.NET Core, and Application Insights had nothing to record.

Direct Line succeeding did not prove that every channel delivery path could connect to the endpoint. It proved that the application and one route to it worked. Copilot and Teams still depended on Microsoft 365 Copilot's agent delivery infrastructure, through Azure Bot Service, successfully negotiating TLS with the App Service front end.

Comparing with a working agent

We compared the complete App Service configuration with a diagnostic agent that was working. Most settings were identical, but one difference stood out:

• Affected App Service: minimum inbound TLS version 1.3.
• Working diagnostic App Service: minimum inbound TLS version 1.2.

The affected App Service rejected clients attempting to connect with TLS 1.2. Microsoft 365 Copilot's agent delivery infrastructure, through Azure Bot Service, needed TLS 1.2 compatibility when connecting to the Agent Framework endpoint. The handshake therefore failed before it could send an HTTP request.

Copilot surfaced the failure as a generic timeout. The Agent Framework application recorded no request or authentication telemetry because the connection never reached it.

The fix

We changed the App Service minimum inbound TLS version from 1.3 to 1.2 and restarted the Web App. Copilot immediately began reaching /api/messages, and the Agent Framework application returned responses successfully.

Setting the minimum TLS version to 1.2 does not disable TLS 1.3. Clients that support TLS 1.3 can still negotiate it. The setting simply permits TLS 1.2 clients as well.

In the Azure portal, this setting is available in the App Service configuration under the platform settings for minimum inbound TLS version. After changing it, restart the App Service and send a new message from Copilot or Teams.

A useful troubleshooting order

When an Azure-hosted Microsoft 365 agent times out, first determine the deepest layer that observed the request:

1. Confirm the messaging endpoint, including the path to /api/messages.
2. Check App Service HTTP logs and Application Insights request telemetry.
3. If the request exists, continue with ASP.NET Core routing, authentication, Agent Framework processing, and dependencies.
4. If no HTTP request exists, move outward to TLS, networking, access restrictions, private endpoints, DNS, and the App Service front end.
5. Compare the complete configuration with a known working deployment instead of comparing only the Azure Bot configuration and application settings.

A timeout is only the user-visible symptom. The presence or absence of server-side telemetry tells us whether to debug inside the application or before it.

Wrapping up

The agent timeout was caused by a one-line App Service configuration difference. The affected App Service required TLS 1.3, while Microsoft 365 Copilot's agent delivery infrastructure through Azure Bot Service needed TLS 1.2 compatibility. The handshake failed before an HTTP request existed, which is why authentication logs, Azure Bot configuration, Agent Framework diagnostics, and Application Insights could not reveal the cause.

When an Azure-hosted Microsoft 365 agent times out without producing HTTP or application telemetry, investigate the network and TLS layers before debugging the Agent Framework code. Comparing the full hosting configuration with a working deployment can expose differences that application-level diagnostics will never see.

Hope this helps!