My Azure bot stopped responding in Teams.

Test the bot from Azure portal → Azure Bot resource → Test in Web Chat first; the result determines whether to troubleshoot the bot application itself or the Teams delivery path.^1^

If Web Chat also fails

1. Check whether the messaging endpoint is reachable
   • Open Azure Bot → Overview and copy Messaging endpoint.
   • Open that URL in a browser.
   • HTTP 404 or 405: the endpoint is reachable; inspect application errors and authentication next.
   • “Site can’t be reached”: the hosted bot is unavailable. Start or redeploy the application.
   • Also confirm the endpoint is HTTPS and includes the correct route, commonly /api/messages.^2^
2. Check the hosting logs while sending a Web Chat message
   • For App Service-compatible hosting: open the hosting resource → Monitoring → App Service logs, enable Application Logging (Filesystem) if needed, save, and then open Monitoring → Log stream.
   • For a Function App, container, or another host, use that platform’s corresponding live logs.
   • Look for inbound /api/messages requests, exceptions, timeouts, and HTTP 401, 403, or 5xx responses. Application Insights can provide availability, performance, and application telemetry when configured.^3^ ^4^
3. Validate how the new secret was deployed
   • Since secret rotation did not restore the bot, do not create another secret yet.
   • Verify the application’s runtime configuration contains the new secret value, not the secret’s ID, and that it belongs to the same App ID configured on the Azure Bot resource.
   • Ensure the application has reloaded the updated setting. Depending on the hosting platform and configuration source, that may require restarting the application.
   • If logs show authentication failures, follow the Bot Framework credential test. It exchanges the App ID and password for a token and distinguishes invalid credentials from endpoint or channel failures.^2^
4. If this is a single-tenant bot or logs show token-refresh 401 errors
   • Open Microsoft Entra ID → App registrations → your bot application.
   • Check whether Managed application in local directory identifies an existing service principal.
   • If it is missing, select Create Service Principal, restart the bot application, and retest.^5^

If Web Chat works but Teams fails

A successful Web Chat test establishes that the endpoint and Bot Framework authentication work on that path; it does not rule out Teams channel configuration, tenant policy, app installation, manifest, or Teams-specific authentication issues.

1. Open Azure Bot → Channels and verify Microsoft Teams is enabled.
2. Confirm that the bot App ID in the Teams app manifest matches the Azure Bot and Entra app registration.
3. Test both a personal chat and a channel. In a channel, explicitly @mention the bot because channel bots normally receive messages only when mentioned.^6^
4. Verify the app remains installed for the affected user or added to the affected team.
5. Compare Teams desktop with Teams on the web. If only one client fails, investigate that client rather than changing the bot registration.
6. If all users and Teams clients fail while Web Chat succeeds, check Azure Bot → Channels → Microsoft Teams for channel errors and review tenant policies or Conditional Access with the Teams/Entra administrator.

Dev-tunnel-only recovery: If the bot is hosted locally through Dev Tunnels or ngrok, direct requests to the tunnel succeed, no inbound activities appear in tunnel inspection, and endpoint/authentication settings are already valid, restart the Microsoft Teams channel on the Azure Bot resource and retest. Restart it rather than deleting and re-adding it; deletion regenerates keys and can invalidate proactive-messaging IDs.^6^

Service health and escalation

Check Azure portal → Service Health for subscription-specific incidents and advisories. The public Azure Status page primarily reports incidents with broad impact, while targeted notifications are delivered through Service Health.^7^

If the failure persists, open an Azure support request and include:

• UTC timestamps and affected conversation scope
• Web Chat versus Teams results
• HTTP status codes and activity/correlation IDs
• Hosting and Application Insights logs
• Azure region and whether all users are affected

Azure subscription access is needed for the Bot resource and Service Health; host access is needed for runtime configuration and logs; Entra or Teams administrator access may be required for service-principal, Conditional Access, and tenant-policy checks.

References

1. Troubleshoot bot configuration issues - Bot Service | Microsoft Learn
2. Troubleshooting Bot Framework authentication
3. Troubleshoot HTTP 500 Internal Service Errors
4. Monitor Azure AI Bot Service
5. Authentication Troubleshooting
6. Troubleshoot your Microsoft Teams app
7. Azure Status Overview - Azure Service Health | Microsoft Learn