ChatOps

WHAT IT IS ChatOps is the practice of performing and recording operational work inside the team's chat surface: bots that execute deployments, queries and remediations; approvals that happen in-channel; and a transcript that becomes a shared, timestamped record of who did what during an event. **Not this:** ChatOps is not IncidentOps: it is the surface through which operational actions are invoked and recorded, not the incident process of detection, command, communication and review. WHY IT EXISTS Operational knowledge concentrates in the people who know which terminal to open. Moving common actions into a shared surface distributes that capability and, more importantly, makes the work observable: everyone in the channel sees the action, its output and its consequence, which is worth a great deal during an incident and again during the review. The transcript is a genuine artifact, not a by-product. WHEN TO USE IT Adopt it when operational actions are concentrated in a few people, when incident timelines have to be reconstructed from memory, or when onboarding an on-call engineer means teaching them a folder of local scripts. Do not adopt it to avoid building proper tooling — a chat command wrapping an unsafe operation is still an unsafe operation, now easier to invoke. WHO OWNS IT The platform or operations team owns the bot, its command surface and its integrations. Security owns the authorization model — this is the item most often skipped, because chat feels informal while the actions are not. Each command's owning team owns what it does. The incident process that uses the surface belongs to /incidentops. WHAT GOOD LOOKS LIKE Commands authenticate and authorize the invoking person against the same model as every other interface, rather than trusting channel membership. Destructive actions require explicit confirmation and are recorded in the audit trail, not only in the chat log. Output is legible in-channel. Commands are discoverable and documented in the surface itself. The dependency is understood: a team that can only operate through chat has made its chat provider a production dependency, and needs a defined path for when it is unavailable. HOW TO IMPLEMENT Start with read-only commands — status, health, recent deploys — which deliver most of the shared-context benefit with none of the risk. Build the authorization model before the first action that changes anything, mapping chat identity to the same roles your other interfaces use. Add write commands narrowly, each with confirmation and audit. Document the fallback for when chat is down. Keep the command set small enough to remember; an undiscoverable command is an unused one. The procedures the commands support belong in /runbooks. HOW TO ASSESS YOURSELF Ask whether a chat command could be run by someone who should not be able to run it. Ask what happens operationally if the chat provider is unavailable. Ask whether last month's incident timeline could be reconstructed from the transcript. Take the scored self-assessment at /assess and plan with /roadmaps.