Will it duplicate posts on every run?

Only if you don't track state. Have the agent keep the incident IDs it already posted and their last-seen status, then post a new line only for fresh incidents or genuine status changes.

Can it acknowledge or resolve incidents from chat?

PagerDuty's server can, through manage_incidents, but this recipe is read-then-post by design. Adding the write side means the agent acts on PagerDuty, which you'll want behind a confirmation step.

Does posting happen the moment an incident triggers?

No. The server answers calls rather than pushing events, so the channel lags by your polling interval. A two-minute loop keeps it close enough for most on-call rotations.

PagerDutyMattermost

Post PagerDuty incidents to Mattermost

A PagerDuty + Mattermost agent flow

The person who gets paged knows about the incident. The rest of the team, the ones who could pull a graph or roll back a deploy, often don't until someone thinks to type it out in chat. This recipe closes that gap for a team that lives in self-hosted Mattermost. Your agent reads open PagerDuty incidents and posts them into the channel where the on-call conversation already happens. It calls list_incidents filtered to triggered and acknowledged states, then writes each one with post_message: the title, the affected service, the urgency, and a link back to PagerDuty. Nothing streams. The PagerDuty server replies when asked, so the agent runs on a short loop and the channel mirrors what's open without anyone copy-pasting from the incident list.

The flow

PagerDutylist_incidents

Lists incidents.

Mattermostpost_message

Post a message to a channel.

Step by step

Pick the incidents and the channel
Give the agent your PagerDuty service or team IDs and a Mattermost channel ID. Decide which states count: usually triggered plus acknowledged, so resolved ones drop off.
Pull the open list
The agent calls list_incidents with a statuses filter and your service scope, getting back each incident's title, urgency, service, assignment, and its PagerDuty URL.
Write it into the channel
It calls post_message for each open incident with a one-line summary and the link, so anyone in the channel can click through and pick it up.
Track state between runs
Store the incident IDs and their last status. On the next pass, post only new incidents and status changes, so the channel reflects movement instead of repeating the same backlog.

Tell your agent

Every two minutes, list PagerDuty incidents in triggered or acknowledged state for the Payments service. Post each new one to the Mattermost channel 'incidents' with its title, urgency, assignee, and PagerDuty link, and post a follow-up when one gets acknowledged or resolved.

Setup

This flow needs both servers connected to your agent. Follow each install guide:

PagerDuty install guide Mattermost install guide

Worth knowing

post_message takes a Mattermost channel ID, not a channel name. Resolve it once with get_channel_by_name and reuse the ID, and make sure the bot account has joined that channel first.
list_incidents defaults can be broad. Pass an explicit statuses filter and a service or team scope, or the agent will pull resolved history and over-post.
PagerDuty urgency (high vs low) is separate from incident status. If you only want to wake the channel for high-urgency incidents, say so, since list_incidents returns both.

Questions

Will it duplicate posts on every run?: Only if you don't track state. Have the agent keep the incident IDs it already posted and their last-seen status, then post a new line only for fresh incidents or genuine status changes.
Can it acknowledge or resolve incidents from chat?: PagerDuty's server can, through manage_incidents, but this recipe is read-then-post by design. Adding the write side means the agent acts on PagerDuty, which you'll want behind a confirmation step.
Does posting happen the moment an incident triggers?: No. The server answers calls rather than pushing events, so the channel lags by your polling interval. A two-minute loop keeps it close enough for most on-call rotations.