Teams error 502 Bad Gateway: 502 - bot returned an error / service dependency failure

502 wears two hats in the Bot Framework, and telling them apart is the whole diagnosis. Hat one: the Connector's own 502. The Teams status table lists 502 as code ServiceError, "Service dependency issue," retry Yes with exponential backoff - a transient fault between Microsoft services while delivering your outbound call. If your send failed with 502, back off and retry; the rate-limit guide names 502 among the codes that "must also be retried."

Hat two - the one that usually brings people here: YOUR endpoint failed. When a channel delivers an activity to your messaging endpoint and your code times out, throws, or returns 5xx, the channel reports it as a 502. The Direct Line reference documents this precisely: "502 - The bot is unavailable or returned an error. This is a common error code," with the canonical body {"error":{"code":"BotRejectedActivity","message":"Failed to send activity: bot returned an error"}}. That is the error you see while testing in Web Chat or the Emulator when the bot's own code is broken.

The cruelty of hat two is the asymmetry between what the user sees and what the log shows. In client surfaces that surface errors (Web Chat, Emulator) you get a generic could-not-send indication; in Teams itself a failed reply is mostly silence - the user's message posts, nothing comes back. Meanwhile the truth (the stack trace) is only in your endpoint's logs or Application Insights. Debug the bot, not the gateway: Microsoft's troubleshoot-500 guide (enable Application Insights, query exceptions, check the adapter's error handler) is the documented route, and the endpoint-side checklist is causes 4 and 8 of Teams bot not responding.

HTTP/1.1 502 Bad Gateway

{
  "error": {
    "code": "BotRejectedActivity",
    "message": "Failed to send activity: bot returned an error"
  }
}

Make your endpoint boring: answer every activity fast, push slow work to a queue, and never let an exception escape the adapter unlogged. Wire health checks and alerting to the endpoint itself, because Teams will not tell your users anything useful when it fails. Keep Application Insights on from day one - the difference between a five-minute and five-hour 502 investigation is whether the telemetry already exists. Endpoint reachability testing is covered step by step in the webhook debugging guide.