Microsoft Teams is the channel for organisations that run their day on Teams. UptimeWire posts one card in the channel you choose when a website goes down, and one when it comes back.
Note
The Teams channel is built and tested against a strict stand-in and a check of the card format. A real message to a live Teams channel has not been independently confirmed yet, and this is the least certain of the chat channels. Use the test message, and check that the card appears in the channel.
Microsoft Teams is a trademark of its owner. UptimeWire is not affiliated with or endorsed by Microsoft.
What it carries
Outage and recovery alerts. Certificate, domain, and DNS warnings are not sent to Teams. They arrive by email and Telegram.
Set it up
Teams uses a workflow made in the Workflows app, not the older Office 365 connector.
- In Teams, open the Workflows app and search for webhook.
- Choose a template that posts to a channel when a webhook request is received, then pick the team and channel.
- Save it and copy the address shown on the workflow's page.
Then, in your UptimeWire account, open the notification settings of your profile, paste the address into the Microsoft Teams card, and press "Connect". Press "Send test message" and look for the card in the channel.
Only the account owner can add, change, test, or remove the address. The address is one per account, so the same Teams channel receives alerts for every website.
Which addresses are accepted
UptimeWire accepts a Workflows address on api.powerplatform.com or logic.azure.com, and it must carry the sig= part that makes it work. Old addresses ending in webhook.office.com are refused with a message that Microsoft stopped this kind of address in May 2026 and that you should make a new one with the Workflows app.
Warning
The workflow belongs to the person who made it. If they leave, give it a second owner, or the alerts may stop. The address also acts like a password for posting to your channel, so do not share it.
What a message looks like
Each alert is an adaptive card with a bold title, Shop is down in red or Shop is back up in green. It lists the website address, the cause (for an outage), how long it was down (for a recovery), and the time the incident started in UTC. Two buttons, "Open site" and "Open incident", sit under it.
Delivery and limits
- Teams accepts first, posts later. A workflow answers that it took the request before the card is posted. When Teams answers like this, the test result says that Microsoft Teams accepted the test message and asks you to check that it appeared. The delivery log shows these as "Accepted". A broken workflow on your side would not be visible to UptimeWire.
- Slow pacing. Messages to one address are sent 12 seconds apart, because Teams limits how often a workflow can post. If many websites fail together, the last alert can arrive some minutes late.
- If Teams refuses a message, or no longer accepts the address, UptimeWire does not retry, and the log shows "The service no longer accepts this address: connect it again". For other failures, it tries up to five times: at once, then after 1, 5, 30, and 120 minutes.
- The delivery log in your account shows the last five Teams messages.
- From the Business plan. If an account moves to a plan without Teams, waiting alerts are cancelled. The address is kept and works again after an upgrade.
- An alert can, in rare cases, arrive twice.
Troubleshooting
- UptimeWire refuses the address. Make sure it comes from the Workflows app and contains
sig=. Addresses ending inwebhook.office.comare not accepted. - The test said "accepted" but nothing appeared. Open the workflow in Teams and look at its run history. UptimeWire cannot see what happens after the workflow accepts the request.
- Alerts stopped after the workflow's owner left. Give the workflow a new owner, or make a new one and connect it.
- You need SSL, domain, or DNS warnings. Use email or Telegram for those.