Bot Framework dropped/delayed messages from Teams

Question

Bot Framework dropped/delayed messages from Teams

Matt Williams 40 Microsoft Employee

We have a number of Teams channels containing a bot, which is backed by the Azure Bot service, which is backed by an Azure Web App written in Python using the Bot Framework SDK v4. This was generally working correctly until 07:17 UTC on Wednesday 11 March, and then all actions started being responded to with Teams' generic "something went wrong" error message, and no requests reached our Web App (all logs stopped). According to the Web App, it did not suffer an outage at that time. At 07:30 UTC, service recovered.

Interestingly, at 07:30 UTC, the Web App received a message that our users tell me was sent some minutes earlier, but the timestamp in the Activity JSON body is for 07:30. To me, this suggests that the issue was not with connectivity between the Bot Service and the Web App, but that the Bot Service was not processing messages from Teams in that window.

The rate at which we were sending messages was low (no more than 1 message every 10-15s), so we should not have been hitting any rate limits, and didn't see any logs relating to that.

The system is now recovered, but I'm keen to understand how we avoid this happening again. I'd also like to know if there are ways that, if this does happen, messages can be dropped rather than delayed - there are circumstances in which a delayed message might have a worse effect on our system than an entirely-dropped one.

I tried looking at the Kusto queries at https://learn.microsoft.com/en-us/azure/bot-service/monitor-bot-service?view=azure-bot-service-4.0#kusto-queries, but these didn't give any results at all, even when I reduced filtering, so maybe Kusto logging is disabled in some way for my Bot Service - is that possible?

Matt Williams 40 Reputation points Microsoft Employee

2026-03-16T13:56:14.3866667+00:00

Thanks! I've enabled the additional diagnostics, so I should have those for next time this happens.

Please can you elaborate on the staleness check? I'm definitely happy to check the activity.timestamp field but, in this case, it was set to the current time, even though the user is adamant that they clicked it several minutes earlier. Is the activity.timestamp field filled in by Teams? ...or is it filled in some time later, when the message arrives at the Bot Service? (It appears the latter.) If it is the latter, how does the staleness check work?
SRILAKSHMI C 18,035 Reputation points Microsoft External Staff Moderator

2026-03-17T07:45:19.5266667+00:00
Hi Matt Williams,

Thank you for the followup,

How activity.timestamp actually works

In the Microsoft Teams → Azure Bot Service → bot pipeline, the activity.timestamp:

Is not guaranteed to represent the exact time the user clicked/sent the message

Is typically set (or normalized) when the activity is processed by the channel/service layer, not strictly at the client (Teams) side

So your observation is correct, The timestamp reflects when the message was delivered to Bot Service, not when the user originally interacted.

This is why your delayed message appeared with a “fresh” timestamp the system effectively treated it as a newly delivered activity after recovery.

Implication for staleness checks

Because of this behavior You cannot rely solely on activity.timestamp to detect delayed messages, A simple “compare timestamp vs current time” approach will fail in backlog scenarios like this

What actually works,

To implement a reliable staleness check, you need to introduce your own notion of time/context, rather than relying only on the platform timestamp.

1: Use client-generated timestamps

If you're using Adaptive Cards, Message actions / buttons

You can embed a timestamp when the action is created.

Example:

{

Then in your bot Read clientTimestamp,Compare with current time, Drop if too old

This is the most reliable method, because it reflects actual user interaction time and it bypasses channel buffering/retry behavior

2: Use activity IDs / deduplication + state

Track message/activity processing using:

activity.id

Conversation state (e.g., last processed action)

Stored timestamps on your side

You can Ignore duplicate or late-arriving actions, Enforce idempotency

3: Add server-side expiration logic

If your bot sends interactive messages (cards/buttons), store metadata like:

Message ID

Creation timestamp

Expiry window

When a response comes in Look up original message context, Reject if expired

Why the platform behaves this way

The behavior you observed is consistent with:

Temporary disruption in the channel pipeline

Messages being queued or retried upstream

Delivery happening only after recovery

At that point:

The system emits a new activity event

With a fresh timestamp

Without preserving original client-side send time

Thank you!
Matt Williams 40 Reputation points Microsoft Employee

2026-03-17T07:56:11.59+00:00

OK, thanks! Unfortunately, that doesn't work for our use case. It's quite possible that a user will not respond immediately to an action, and I think it would cause a lot of frustration if the bot replied saying "you didn't respond to my action within 5 minutes (say), so I'm going to reject your request".

Is there any plan to improve the behavior around the activity timestamp, so that it does reflect the time of the user's activity, rather than an arbitrary time after?
SRILAKSHMI C 18,035 Reputation points Microsoft External Staff Moderator

2026-03-18T03:35:49.1766667+00:00
Hi Matt Williams,

Thanks for the detailed context

About activity.timestamp

Your understanding is correct:

In the Microsoft Teams → Bot Framework → Azure Bot Service pipeline, the activity.timestamp is not guaranteed to represent the exact user action time.

It is typically assigned or normalized when the activity is processed/delivered by the channel service, not when the user clicks in Teams.

During transient issues (like the one you observed), messages can be queued upstream and delivered later, at which point they receive a fresh timestamp.

Is there a plan to change this behavior?

As of today, there is no publicly documented plan or committed change to make activity.timestamp reliably reflect the original client-side interaction time in Teams.

This behavior is largely due to how the channel infrastructure is designed:

Messages may pass through multiple services (Teams → channel connector → Bot Service)

Reliability mechanisms (retries, buffering) can delay delivery

Not all channels consistently preserve original client timestamps

Because of this, the Bot Framework schema does not guarantee end-to-end timestamp fidelity across channels, including Teams.

Thank you!
SRILAKSHMI C 18,035 Reputation points Microsoft External Staff Moderator

2026-03-20T11:52:00.5966667+00:00

Hi Matt Williams,

Did you get any chance to review the above response. Do let me know if you have any further queries.

Thank you!
Matt Williams 40 Reputation points Microsoft Employee

2026-03-20T14:57:36.4266667+00:00

Yes, that's clear - thanks! I'm not sure I have a solution, but I think I understand the position.
SRILAKSHMI C 18,035 Reputation points Microsoft External Staff Moderator

2026-03-23T06:42:33.2266667+00:00

Hi Matt Williams,

Thanks for confirming. Since I’ve converted my earlier comment into an answer, could you please take a moment to mark it as Accepted? This helps others in the community with the same question find the solution more easily.

Thank you!

Answer accepted by question author

0 additional answers

Your answer

Matt Williams 40 Reputation points Microsoft Employee

2026-03-16T13:56:14.3866667+00:00

Thanks! I've enabled the additional diagnostics, so I should have those for next time this happens.

Please can you elaborate on the staleness check? I'm definitely happy to check the activity.timestamp field but, in this case, it was set to the current time, even though the user is adamant that they clicked it several minutes earlier. Is the activity.timestamp field filled in by Teams? ...or is it filled in some time later, when the message arrives at the Bot Service? (It appears the latter.) If it is the latter, how does the staleness check work?
Matt Williams 40 Reputation points Microsoft Employee

2026-03-17T07:56:11.59+00:00

OK, thanks! Unfortunately, that doesn't work for our use case. It's quite possible that a user will not respond immediately to an action, and I think it would cause a lot of frustration if the bot replied saying "you didn't respond to my action within 5 minutes (say), so I'm going to reject your request".

Is there any plan to improve the behavior around the activity timestamp, so that it does reflect the time of the user's activity, rather than an arbitrary time after?
SRILAKSHMI C 18,035 Reputation points Microsoft External Staff Moderator

2026-03-18T03:35:49.1766667+00:00

Hi Matt Williams,

Thanks for the detailed context

About activity.timestamp

Your understanding is correct:

In the Microsoft Teams → Bot Framework → Azure Bot Service pipeline, the activity.timestamp is not guaranteed to represent the exact user action time.

It is typically assigned or normalized when the activity is processed/delivered by the channel service, not when the user clicks in Teams.

During transient issues (like the one you observed), messages can be queued upstream and delivered later, at which point they receive a fresh timestamp.

Is there a plan to change this behavior?

As of today, there is no publicly documented plan or committed change to make activity.timestamp reliably reflect the original client-side interaction time in Teams.

This behavior is largely due to how the channel infrastructure is designed:

Messages may pass through multiple services (Teams → channel connector → Bot Service)

Reliability mechanisms (retries, buffering) can delay delivery

Not all channels consistently preserve original client timestamps

Because of this, the Bot Framework schema does not guarantee end-to-end timestamp fidelity across channels, including Teams.

Thank you!
SRILAKSHMI C 18,035 Reputation points Microsoft External Staff Moderator

2026-03-20T11:52:00.5966667+00:00

Hi Matt Williams,

Did you get any chance to review the above response. Do let me know if you have any further queries.

Thank you!
Matt Williams 40 Reputation points Microsoft Employee

2026-03-20T14:57:36.4266667+00:00

Yes, that's clear - thanks! I'm not sure I have a solution, but I think I understand the position.
SRILAKSHMI C 18,035 Reputation points Microsoft External Staff Moderator

2026-03-23T06:42:33.2266667+00:00

Hi Matt Williams,

Thanks for confirming. Since I’ve converted my earlier comment into an answer, could you please take a moment to mark it as Accepted? This helps others in the community with the same question find the solution more easily.

Thank you!

Answer 1

Hello Matt Williams,

Welcome to Microsoft Q&A and Thank you for the detailed timeline and observations.

Based on the behavior you described, it does appear that the issue likely occurred upstream of your Web App, since:

Your bot did not receive any requests during the incident window

Teams users saw the generic “something went wrong” error

Your App Service logs show no downtime

A message that users sent earlier was delivered later with a new timestamp

This pattern generally suggests a temporary disruption within the Microsoft Teams → Bot Framework channel infrastructure, rather than an issue with the bot’s hosting environment.

What likely happened

The message flow for a Teams bot typically looks like this:

Teams client → Teams service → Bot Framework channel service → Azure Bot Service → your bot endpoint

Because your Web App never received requests during the ~07:17–07:30 UTC window, it’s likely that the issue occurred within the Teams channel connector or Bot Service layer, where messages may have been temporarily queued or retried. Once the upstream service recovered, the messages were forwarded to your bot, which explains why you later received an activity with a new timestamp corresponding to the delivery time.

Enable detailed logging for future troubleshooting

To better understand events like this in the future, it would be helpful to enable diagnostic logging for your bot resource.

In the Azure portal, open your bot resource.

Go to Diagnostic settings.

Enable Send to Log Analytics (or Storage/Event Hub if preferred).

Once enabled, you should be able to run the Kusto queries provided in the documentation to see channel activity, request attempts, and response codes. If diagnostic logging is not enabled, those queries will return no results, which may explain what you observed earlier.

Reference: Bot Service monitoring queries https://learn.microsoft.com/azure/bot-service/monitor-bot-service?view=azure-bot-service-4.0#kusto-queries

Use Application Insights for end-to-end visibility

It can also help to capture telemetry on both sides of the pipeline:

Bot Service registration – link an Application Insights instance to capture channel connector traces.

Your Web App – enable Application Insights to capture exceptions, request latency, and dependency calls.

This makes it easier to correlate activity between the Teams channel layer and your bot backenMonitor service health

Because incidents like this can sometimes originate in the platform layer, it is recommended to:

Subscribe to Azure Service Health alerts in the Azure portal.

Monitor the Azure status page for regional service incidents.

These alerts can notify you if there are channel outages or service degradations affecting bots in your region.

Handling delayed messages

At the moment, Azure Bot Service does not provide a built-in mechanism to drop delayed messages at the channel level. Messages will generally be delivered once the service recovers.

If delayed messages could cause issues in your system, a common mitigation is to implement a message staleness check in your bot code. For example:

Inspect the activity.timestamp field in each incoming message.

Compare it with the current server time.

Ignore messages that exceed your acceptable age threshold (for example, older than 30–60 seconds).

This effectively allows your bot to discard stale messages rather than process them after a backlog is cleared.

The behavior you observed likely resulted from a temporary issue in the Teams → Bot Service channel pipeline, not your Web App.

Diagnostic logs and Application Insights can help trace channel activity and delivery attempts.

Azure Service Health alerts can notify you if similar platform incidents occur.

Since Teams does not currently support message TTL for bots, you can add a timestamp check in your bot logic to ignore delayed messages.

Please refer this

Monitor Bot Service with Kusto: https://learn.microsoft.com/azure/bot-service/monitor-bot-service?view=azure-bot-service-4.0#kusto-queries
General troubleshooting for Azure AI Bot Service bots: https://learn.microsoft.com/azure/bot-service/bot-service-troubleshoot-general-problems?view=azure-bot-service-4.0
How to guarantee message delivery order: https://learn.microsoft.com/azure/bot-service/bot-service-troubleshoot-general-problems?view=azure-bot-service-4.0#how-can-i-guarantee-message-delivery-order
Status codes & retry guidance for Teams bots: https://learn.microsoft.com/microsoftteams/platform/bots/build-conversational-capability?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#status-codes-from-bot-conversational-apis

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

Thank you!

Share via

Bot Framework dropped/delayed messages from Teams

0 additional answers

Your answer