Post Argo CD sync drift to a Rocket.Chat channel
A Argo CD + Rocket.Chat agent flow
Argo CD reconciles clusters to what's in Git, and when an application drifts to OutOfSync or its health goes Degraded, the team needs to know before a customer does. A group running GitOps on Rocket.Chat wants the unhealthy or drifted apps surfaced in their deploys channel without anyone opening the Argo CD dashboard. The agent reads the application list with list_applications, picks out the ones whose sync or health status changed for the worse since last run, and posts them to Rocket.Chat with send_message. Argo CD answers the call, so you set the cadence and the agent reads then writes on it.
The flow
list_applicationsLists and filters Argo CD applications.
send_messageSend a message to a channel.
Step by step
- Decide which states are worth a post
Typically OutOfSync sync status or Degraded and Missing health. Point the agent at one Rocket.Chat channel and resolve it once with get_channel_info.
- List applications
The agent calls list_applications and reads each app's name, sync status, and health status. The tool filters, so you can scope to a project or a label if the cluster has many apps.
- Compare to the last snapshot
Store each app's sync and health from the prior run. Post when an app crosses into a bad state, and once when it returns to Synced and Healthy, so a long-degraded app doesn't post every poll.
- Send to Rocket.Chat
For each changed app the agent calls send_message with the app name, the new sync and health, and a link, so the channel sees which deploy drifted and where.
Tell your agent
Every two minutes, list Argo CD applications in the prod project. For any app that just went OutOfSync or whose health dropped to Degraded or Missing, post to the #deploys Rocket.Chat channel with the app name, sync status, health, and a link. Post one recovery line when it returns to Synced and Healthy, and don't repeat while it stays bad.
Setup
This flow needs both servers connected to your agent. Follow each install guide:
Worth knowing
- list_applications returns current sync and health, not a change feed, so the agent has to diff against the last snapshot to catch the transition into a bad state rather than posting the whole roster each run.
- An app mid-deploy may briefly read OutOfSync while it reconciles. A short grace check, only post if it's still bad on the next poll, avoids crying drift during a normal rollout.
- send_message posts to a channel by name or ID. Confirm the channel exists and the bot is a member, or the post silently fails and the drift goes unseen.
Questions
- Does it catch a deploy that fails to sync?
- Yes. A failed sync shows up as OutOfSync or a Degraded health on the next list_applications read, and the diff posts it. The post trails the failure by your polling interval.
- Can it scope to one project or team's apps?
- Yes. list_applications filters, so the agent can read only a given project or a labeled set, and post only those to the channel that owns them.