Failures sending messages back to users starting chats with bots from Microsoft Teams

Question

Failures sending messages back to users starting chats with bots from Microsoft Teams

Eric Richards 91

Starting about 03/24/2026 12:30 EDT, all attempts to respond to incoming chat requests from Microsoft Teams users in our various Bot Framework bots started failing.

There's a whole array of error responses and exceptions raised, but we're seeing about 85-90% of requests made to smba.trafficmanager.net fail. Timeouts, bad gateway errors, socket errors, etc.

Requests that are coming in through the direct-line and webclient channels are not experiencing these problems, only those through the msteams channel.

Doesn't appear to be constrained to any specific Azure Bot; we are seeing basically complete failures with any attempts to send messages back to Teams users. This is across multiple entirely different bot codebases, as well. Trying to use some other Teams apps that have a bot component (Trello, Hubspot, others) and none of them are responding in Teams either.

Anshika Varshney 9,740 Reputation points Microsoft External Staff Moderator

2026-03-24T19:39:21.41+00:00

Hi Eric Richards,

Thanks for sharing the details. Based on what you described, this does not look like a problem in your bot code because the same bots still work on Direct Line and web chat, but replies fail only when the request is coming from the Teams channel. Your post also mentions that other third party Teams apps with bot components stopped responding at the same time, which strongly points to a Teams channel delivery problem rather than an issue in one specific bot.

In Teams, bots send replies back using the serviceUrl provided in the incoming activity. For Teams, that serviceUrl is typically the smba.trafficmanager.net endpoint, which is the Bot Framework Connector base address for Teams conversations. If that endpoint is returning timeouts or bad gateway responses, the bot cannot deliver messages back to the user even though it is receiving incoming messages.

Here are a few practical things you can do to confirm and reduce impact.

First, check if there is an active Teams service issue. Microsoft recommends checking the Service health page in the Microsoft 365 admin center when a Microsoft service suddenly starts failing, so you can confirm if it is a known incident before spending time on local debugging. If you cannot access the admin center, Microsoft also provides a public service status page you can use to see if Microsoft 365 has a known issue. [learn.microsoft.com] [learn.microsoft.com], [status.clo....microsoft]

Next, confirm nothing changed in your bot configuration for the Teams channel. In Azure Bot Service, the Teams channel must be enabled and correctly configured for routing bot traffic in Teams. If the channel is enabled and was working before today, this step is mainly to rule out accidental configuration changes. [learn.microsoft.com]

Then, validate basic network connectivity from your bot host to the channel endpoints. Microsoft’s bot troubleshooting guidance suggests using the App Service Kudu console to run quick DNS and connectivity checks when a bot can’t reach a channel endpoint. The doc shows this approach using nslookup and curl as simple checks. You can apply the same idea to confirm your environment can resolve and reach the Teams connector endpoint. [learn.microsoft.com]

Also, if your bot is using the Connector REST API directly, make sure you are replying to the exact serviceUrl you received in the incoming activity instead of hard coding a Teams base URL. Microsoft’s Connector API reference explains that the incoming activity includes the serviceUrl and you should use that value as the base URI for replies. [learn.microsoft.com]

Finally, for short term resilience, it helps to treat these as transient failures. Timeouts and bad gateway responses from a dependency are often temporary. If you are not already doing it, consider adding retry with backoff around the send activity call and log the serviceUrl, timestamp, and the response status so you can correlate failures. This is a general reliability best practice when dealing with intermittent upstream gateway issues.

If you want to add one helpful data point to the thread, share one example timestamp plus the HTTP status you get when posting to the Teams serviceUrl, because that helps confirm whether it is a broader Teams connector issue versus a tenant specific block.

I Hope this helps. Do let me know if you have any further queries.

Thank you!
Anshika Varshney 9,740 Reputation points Microsoft External Staff Moderator

2026-03-28T09:42:54.86+00:00

Hi Eric Richards,

Thank you for your response in the private chat. I understand the frustration here. What you are describing does happen occasionally with Teams and Bot Framework, where message delivery fails for a period and then recovers without any action on the customer side. These are typically transient backend issues and do not always show up on public service health pages, especially if the impact is limited in scope or duration.

Unfortunately, when this happens, there is not much that can be done from the bot configuration side. Once the underlying service recovers, message delivery usually starts working again, which matches the behavior you are seeing.

Thankyou!
Anshika Varshney 9,740 Reputation points Microsoft External Staff Moderator

2026-03-30T18:31:32.6833333+00:00

Hi Eric Richards,

Did you get any chance to review the response.

Thankyou!
Eric Richards 91 Reputation points

2026-03-30T18:44:23.4533333+00:00

I'm not surprised by the lack of transparency and abdication of responsibility.
Manas Mohanty 16,190 Reputation points Microsoft External Staff Moderator

2026-04-02T08:08:06.6066667+00:00

Hi Eric Richards

Sorry for the trouble.

Wanted to quote that -Not all transient service disruptions are published as official outages or followed by public incident reports. This typically depends on factors such as scope, duration, and overall service impact. When an issue resolves quickly or affects a narrow subset of scenarios, it may not meet the threshold for a formal incident communication, even though the impact to those affected is understandably significant.

From a support perspective, once we confirm that the behavior is service‑side and not caused by customer configuration or code changes

Could you fill the details like Resource id of Bot service, Foundry Service along the error trace in Support ticket link provided by private message.

We appreciate you calling out the experience, and feedback like this is important. It helps highlight where additional transparency would be valuable, even for short‑lived issues.

Thank you for your inputs.

1 answer

Your answer

Anshika Varshney 9,740 Reputation points Microsoft External Staff Moderator

2026-03-28T09:42:54.86+00:00

Hi Eric Richards,

Thank you for your response in the private chat. I understand the frustration here. What you are describing does happen occasionally with Teams and Bot Framework, where message delivery fails for a period and then recovers without any action on the customer side. These are typically transient backend issues and do not always show up on public service health pages, especially if the impact is limited in scope or duration.

Unfortunately, when this happens, there is not much that can be done from the bot configuration side. Once the underlying service recovers, message delivery usually starts working again, which matches the behavior you are seeing.

Thankyou!
Anshika Varshney 9,740 Reputation points Microsoft External Staff Moderator

2026-03-30T18:31:32.6833333+00:00

Hi Eric Richards,

Did you get any chance to review the response.

Thankyou!
Eric Richards 91 Reputation points

2026-03-30T18:44:23.4533333+00:00

I'm not surprised by the lack of transparency and abdication of responsibility.
Manas Mohanty 16,190 Reputation points Microsoft External Staff Moderator

2026-04-02T08:08:06.6066667+00:00

Hi Eric Richards

Sorry for the trouble.

Wanted to quote that -Not all transient service disruptions are published as official outages or followed by public incident reports. This typically depends on factors such as scope, duration, and overall service impact. When an issue resolves quickly or affects a narrow subset of scenarios, it may not meet the threshold for a formal incident communication, even though the impact to those affected is understandably significant.

From a support perspective, once we confirm that the behavior is service‑side and not caused by customer configuration or code changes

Could you fill the details like Resource id of Bot service, Foundry Service along the error trace in Support ticket link provided by private message.

We appreciate you calling out the experience, and feedback like this is important. It helps highlight where additional transparency would be valuable, even for short‑lived issues.

Thank you for your inputs.

Answer 1

Hello Eric Richards,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you're having failures sending messages back to users starting chats with bots from Microsoft Teams.

The failure originated from a temporary Microsoft Teams service‑side disruption affecting the Bot Framework Connector endpoint (smba.trafficmanager.net), preventing outbound bot messages while inbound messages continued to flow normally.

Since this type of connector degradation is not remediable through configuration or code changes, the correct approach is to validate service health, avoid modifying bot settings, apply temporary fallbacks, and resume normal operations once Microsoft completes restoration. This ensures operational continuity while adhering to Microsoft’s recommended recovery practices for Teams bot reliability.

The remediation steps below will help you to fix the issue:

Use the Microsoft 365 Admin Center service‑health portal and Microsoft’s public service‑status page to confirm active Teams‑related incidents impacting bot delivery. Microsoft 365 Service Health, and Microsoft Service Status
Check whether outbound calls to the Microsoft‑managed Teams connector endpoint fail: https://smba.trafficmanager.net/ Common failure signals include 502, 504, or repeated socket timeouts. These conditions indicate platform‑side faults as defined in Microsoft Bot Connector networking documentation. - https://learn.microsoft.com/azure/bot-service/bot-service-resources-connectors>
Do not regenerate secrets, modify Teams channel settings, or redeploy manifests. The inbound path functioning correctly confirms your bot configuration is intact. - https://learn.microsoft.com/microsoftteams/platform/bots/how-to/connect-bot-to-teams
Use a soft‑failure response when outbound delivery fails: "Teams is currently experiencing delivery delays. Please try again shortly." If available in your architecture, route critical interactions through Direct Line or Web Chat, which operate independently of the Teams connector. - https://learn.microsoft.com/azure/bot-service/bot-service-channel-directline Also record outbound delivery failures for later reconciliation: Log(serviceUrl, conversationId, httpStatus, timestamp)
Because connector outages are Microsoft‑side service incidents, remediation is completed solely by Microsoft engineering. Monitor service‑health notifications until recovery is published, you have to wait.
After Microsoft resolves the incident:
- Send proactive bot messages.
- Confirm replies in Teams chats succeed.
- Verify updated serviceUrl values in Activities.
- Ensure 200 OK responses from smba.trafficmanager.net.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Share via

Failures sending messages back to users starting chats with bots from Microsoft Teams

1 answer

Your answer