🚨 Microsoft Teams Error Guide: '410 Gone' — Retired Office 365 Connector Webhooks

Overview

Alerts that posted into a Teams channel for years suddenly stop appearing. The cause is Microsoft’s retirement of Office 365 (O365) connectors — the classic office.com/webhook/... and outlook.office.com/webhook/... incoming-webhook URLs. As they are decommissioned, POSTs to those endpoints fail. The clearest signal is an HTTP 410 Gone:

HTTP/1.1 410 Gone
Content-Type: application/json

{
  "error": {
    "code": "Gone",
    "message": "This connector has been retired. Please migrate to Power Automate Workflows."
  }
}

During the phased rollout you may instead see HTTP 400 with a deprecation message, HTTP 404 Not Found, or — worst of all — a 200 OK where the message is silently dropped and never rendered. Any monitoring, CI, or script that still POSTs a MessageCard payload to a connector URL is affected. The fix is not a retry; it is migrating to the Power Automate Workflows inbound webhook.

Symptoms

• Messages that used to appear in a channel simply stop, with no code change on your side.
• POSTs to *.webhook.office.com / outlook.office.com/webhook/* return 410 Gone, 404, or 400 with a retirement/deprecation message.
• The sender logs a 200 OK but nothing renders in the channel (silent drop).
• Legacy MessageCard ("@type": "MessageCard") payloads no longer show, even where the URL still responds.
• Multiple integrations (Alertmanager, Datadog, Grafana, CI, cron scripts) break at once, tied to a retirement date rather than a deploy.

Common Root Causes

1. The connector endpoint has been retired (410 / 404)

The office.com connector URL no longer accepts posts. There is no way to “renew” it — the identity behind the connector is gone.

curl -s -o /dev/null -w "%{http_code}\n" -X POST \
  "https://acme.webhook.office.com/webhookb2/....../IncomingWebhook/......" \
  -H "Content-Type: application/json" \
  -d '{"@type":"MessageCard","@context":"https://schema.org/extensions","text":"test"}'

410

A 410 (or 404) here means the endpoint is dead. Migrate — do not retry.

2. Silent drop of legacy MessageCard payloads (200 but nothing renders)

During the transition some URLs return 200 OK while dropping the message. Relying on the HTTP status alone hides the failure; the only reliable check is whether the card actually appears in the channel.

3. Still sending MessageCard JSON to the new Workflows endpoint

After swapping in the Workflows URL, teams often keep posting the old MessageCard body. The Workflows trigger expects the Adaptive Card message envelope; a MessageCard returns 400 or renders blank.

{
  "@type": "MessageCard",
  "@context": "https://schema.org/extensions",
  "summary": "Deploy",
  "text": "Deploy succeeded"
}

This legacy shape must be rewritten as a wrapped Adaptive Card (see the fix below).

4. The Workflow URL was not stored/rotated as a secret

The Workflows inbound URL contains a signature and is an unauthenticated secret. If it leaked, was regenerated, or the flow was disabled (personal-owned flows disable when the owner goes inactive), posts fail again.

5. Hardcoded connector URLs scattered across systems

The same dead URL is embedded in many places — Alertmanager config, Datadog integrations, cron scripts, Terraform. Missing one leaves a broken alert path.

Diagnostic Workflow

Step 1: Probe the old connector URL and read the status

curl -s -D - -o /dev/null -X POST "$OLD_CONNECTOR_URL" \
  -H "Content-Type: application/json" \
  -d '{"@type":"MessageCard","@context":"https://schema.org/extensions","text":"probe"}' \
  | grep -i '^HTTP'

410/404 = retired. 400 with a deprecation message = mid-retirement. 200 but no card in the channel = silent drop. All three mean: migrate.

Step 2: Inventory every place the connector URL lives

grep -rInE 'webhook\.office\.com|outlook\.office\.com/webhook' \
  /etc /opt ./config ./infra 2>/dev/null

Enumerate all senders (Alertmanager, Datadog, Grafana, scripts, Terraform) so none is missed during cutover.

Step 3: Create the Workflows inbound webhook

In Teams, use the Workflows app template “Post to a channel when a webhook request is received” (Power Automate), pick the target team + channel, and copy the generated HTTPS URL. Own the flow with a service/shared account, not a personal account that may go inactive.

Step 4: Post the correct wrapped Adaptive Card payload

The Workflows trigger expects the message envelope, not a MessageCard:

curl -s -o /dev/null -w "%{http_code}\n" -X POST "$WORKFLOW_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "message",
    "attachments": [
      {
        "contentType": "application/vnd.microsoft.card.adaptive",
        "content": {
          "type": "AdaptiveCard",
          "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
          "version": "1.5",
          "body": [
            { "type": "TextBlock", "text": "Deploy succeeded", "weight": "Bolder", "size": "Medium" },
            { "type": "FactSet", "facts": [
              { "title": "Service", "value": "checkout-api" },
              { "title": "Env", "value": "prod" }
            ]}
          ],
          "actions": [
            { "type": "Action.OpenUrl", "title": "Runbook", "url": "https://runbooks.example.com/deploy" }
          ]
        }
      }
    ]
  }'

202 confirms the new endpoint accepted the wrapped card.

Step 5: Parallel-run, then verify the card renders

Point one sender at the new URL while the old path is still (nominally) in place, and confirm the card actually appears in the channel — status alone is not proof. Then cut the rest over.

Example Root Cause Analysis

An SRE team noticed their Datadog monitor notifications had gone quiet in a #prod-alerts channel for a week. No Datadog change had shipped. Probing the configured webhook:

curl -s -D - -o /dev/null -X POST "$OLD_CONNECTOR_URL" \
  -H "Content-Type: application/json" \
  -d '{"@type":"MessageCard","@context":"https://schema.org/extensions","text":"probe"}' \
  | grep -i '^HTTP'

HTTP/1.1 410 Gone

The O365 connector had been retired on schedule. A repo-wide grep found the same dead URL in the Datadog integration, an Alertmanager receiver, and two cron scripts:

grep -rInE 'webhook\.office\.com' /etc /opt 2>/dev/null | wc -l

4

They created a Workflows inbound webhook owned by a shared svc-teams-alerts account, rewrote the MessageCard bodies as wrapped Adaptive Cards, stored the new URL in the secret manager, and updated all four call sites. A parallel-run post returned 202 and rendered in the channel, confirming the migration before the old references were removed.

Prevention Best Practices

• Migrate every O365 connector webhook to a Power Automate Workflows inbound webhook — the connector endpoints are retired and cannot be renewed.
• Rewrite legacy MessageCard payloads as wrapped Adaptive Cards ({"type":"message","attachments":[{"contentType":"application/vnd.microsoft.card.adaptive", ...}]}); MessageCard JSON will not render on the new endpoint.
• Own each flow with a service/shared account — personal-owned flows silently disable when the owner leaves or goes inactive.
• Treat the Workflow URL as a secret: store it in a secret manager, restrict access, and rotate by regenerating the trigger if it leaks.
• Keep webhook URLs in one config source, not hardcoded across many systems, so migrations touch a single place.
• Add a synthetic post + channel-render check to monitoring so a silent drop is caught in minutes, not after a week of missed alerts.
• Cross-reference connector/webhook failures against the Microsoft Teams guides and the incident assistant.

Quick Command Reference

# Probe the old connector URL and show the HTTP status line
curl -s -D - -o /dev/null -X POST "$OLD_CONNECTOR_URL" \
  -H "Content-Type: application/json" \
  -d '{"@type":"MessageCard","@context":"https://schema.org/extensions","text":"probe"}' \
  | grep -i '^HTTP'

# Find every hardcoded connector URL across configs and scripts
grep -rInE 'webhook\.office\.com|outlook\.office\.com/webhook' /etc /opt ./config 2>/dev/null

# Post a correctly wrapped Adaptive Card to the new Workflows webhook
curl -s -o /dev/null -w "%{http_code}\n" -X POST "$WORKFLOW_URL" \
  -H "Content-Type: application/json" \
  -d '{"type":"message","attachments":[{"contentType":"application/vnd.microsoft.card.adaptive","content":{"type":"AdaptiveCard","version":"1.5","body":[{"type":"TextBlock","text":"migrated"}]}}]}'

# Confirm the new endpoint returns 202 (accepted)
curl -s -o /dev/null -w "%{http_code}\n" -X POST "$WORKFLOW_URL" \
  -H "Content-Type: application/json" -d '{"type":"message","attachments":[]}'

Conclusion

A Teams channel that goes quiet with no code change is the signature of O365 connector retirement. In order of frequency the causes are:

1. The connector endpoint is retired and returns 410 Gone (or 404).
2. A transitional endpoint returns 200 OK but silently drops legacy MessageCard payloads.
3. MessageCard JSON is still being posted to the new Workflows endpoint, which expects a wrapped Adaptive Card.
4. The Workflow URL leaked, rotated, or the flow was disabled because a personal owner went inactive.
5. The dead connector URL is hardcoded in multiple systems, so a partial migration leaves broken paths.

The fastest fix path is: probe the old URL to confirm retirement, grep every place the URL lives, create a service-account-owned Workflows inbound webhook, rewrite payloads as wrapped Adaptive Cards, verify the card actually renders (not just the HTTP status), then cut all senders over. See the Microsoft Teams guides for the full migration playbook.