Aviation students arrive with myths because myths are easier to absorb than systems: the rudder steers the aeroplane on the ground, a licence means you can fly anywhere, fuel gauges deserve trust. Operations teams absorb myths the same way, and since ChatOps — running work out loud in a joint channel, where software robots announce events and carry out just the commands they have been cleared to accept — has been practiced since GitHub’s Hubot opened for business in 2011, its myths have had over a decade to harden. This piece tests six of them against the documented record. The record itself is gathered in the Ops Atlas’s ChatOps notes, and every claim below traces back to it. Evidence first, myth second — that is the only order myths respect.
Where These ChatOps Myths Come From
The practice earned its name from Jesse Newland’s February 2013 talk, and its early fame came from GitHub’s deploy operation — a weekly drumbeat of hundreds of production releases passing through a chat queue protected by guards and locks. Fame breeds folklore. Teams adopted the visible part (a bot in a channel) without the invisible parts (verification, identity, tiered permission, external records), and the folklore grew in exactly those invisible places. Each myth below substitutes something comfortable for something structural.
Myth 1: “The channel history is our audit trail”
The most comfortable myth, and the most falsifiable. Channel history expires under retention policies, allows edits, hides in direct messages, and was designed for conversation rather than evidence. The documented practice keeps an append-only record — NIST’s AU-3 sketches the schema — outside the chat entirely, capturing every command, approval, refusal and override. Chat is where work becomes visible; the record is where work becomes provable. Teams that conflate the two discover the difference during the first serious inquiry, when the relevant week has already scrolled into deletion.
Myth 2: “You can tell who is asking by the name on the message”
Display names are cosmetic fields that anyone can change between two commands. The documented trust chain maps each request to an immutable user ID before any permission decision — precisely because names lie. The related variant, “the platform rejects impostors for us”, fails on the evidence too: platforms prove origin differently, and Mattermost’s static token does not cover the request body, meaning message contents can be altered without breaking anything. Verification is the integrator’s job, not the platform’s gift.
Myth 3: “A thumbs-up is an approval”
An emoji reaction records enthusiasm, not consent. Nothing in a reaction demonstrates the reactor read the request, held the eligible role, or even reacted to the right message in a fast-moving channel. The documented model makes approvals explicit commands from a distinct, eligible account — and for consequential actions enforces the two-person rule, indexed by auditors under NIST AC-3(2) as dual authorisation. Aviation students already learn a version of this: acknowledging a clearance is not the same as receiving one, and someone reading back your read-back is how errors get caught.
Myth 4: “Our bot only posts — it’s harmless”
This one fails twice. First, a posting bot is still a trusted insider: it writes into a channel where people make decisions, which is why the noise question matters — twelve people each spending ten seconds on four hundred unfiltered notices a week adds up to some thirteen hours of attention, and tired readers miss the message that mattered. Second, plenty of bots post and act, and the acting side carries privilege. Frameworks have shipped with defaults that run chat-triggered work under a shared service account — StackStorm’s chatops_bot is the standard example — creating a confused deputy: one identity takes the blame for everyone and answers for no one. The documented remedy is mapping every execution back to the human who requested it. The “harmless” end of the spectrum has a genuinely useful role, though, and the record shows it: the read-only bots used on GOV.UK did nothing but nudge — flagging pull requests gone stale and security scans that never ran — proving that visibility alone, honestly done, changes behaviour without touching a single system.
Myth 5: “The tooling is mature, so the defaults are safe”
Maturity describes the pattern, not every product built on it. The same documented tooling survey that records Hubot at 14.1 and Errbot at 6.2 also records an AI assistant — Amazon Q Developer in chat — defaulting towards AdministratorAccess when guardrails go unset, and StackStorm 3.9 supporting chat operations on Slack alone. Alertmanager 0.34 needs a bot token for message updates because plain webhooks cannot edit, a detail that surprises teams mid-incident. Maturity means the knowledge exists; it has never meant the defaults protect you.
Myth 6: “AI can run the channel now”
The newest myth, refuted most recently. In August 2024, PromptArmor demonstrated prompt injection against Slack AI — the assistant steered through text it should have distrusted. Slack’s February 2026 announcement of an MCP server widens the integration surface further, which raises the stakes on the rule the record now states plainly: assistants propose, humans approve, no model approves another model, and prompts plus tool calls are logged in line with OWASP’s LLM01 and LLM06. Autopilot is a lovely metaphor and a terrible governance model; the record supports copilots, not captains.
Two Stories the Myths Keep Getting Wrong
The folklore version of history says chat ran everything, everywhere, until people got bored of it. The documented version is sharper. By 2021, GitHub had transferred the state of deploys into a state machine driven by a graphical interface — while keeping the chat command as the trigger, because summoning work from a conversation remains the most natural gesture a team has. Trigger in the channel, state in a system of record: that split is the anti-myth, the exact opposite of “the channel is our database”, and it explains why migrations away from dead platforms hurt some teams and bounced off others. The second story is incident response, where the practice’s event-command discipline shows its real shape. A disruption gets declared with one command; a dedicated thread is created; the right person is paged; the timeline assembles itself from the thread’s decisions; and when it ends, one command archives a complete record. Paging commands in the documented pattern fail loudly, switching to a backup route the moment the primary dies, and they report changes rather than re-stating unchanged states. Neither story supports the folklore. Both support the boring, structural truths: state lives elsewhere, evidence lives elsewhere, and the channel’s job is to be the room where everyone watches the work happen.
What the ChatOps Record Actually Supports
Strip the myths away and the documented practice is almost disappointingly sensible. Verify where each request truly came from, using each platform’s own proof — signatures with replay limits and short acknowledgement windows on one, signed tokens on another, a weak static token on a third. Resolve requesters to permanent IDs. Grade actions from information through read, reversible write and consequential change, reserving the top grade for two people and keeping a logged emergency bypass. Refuse anything that does not match an approved pattern — free text never touches a shell. Write the evidence outside the chat. Review refusals weekly and re-audit scope quarterly. Measure what matters: audited change coverage (93.9% in a published example), command success (98.1% in the same set), refusal mix, approval latency, actionable-notification share (23% measured against a 50% goal). Ignore raw counts, which flatter while they mislead. And keep the whole apparatus portable, because the platforms keep retiring — HipChat and Stride gone, legacy custom bots ended at Slack in March 2025, Office 365 Connectors leaving Teams in 2026, Opsgenie dark in 2027 — while the pattern itself, fifteen years old and counting, simply changes aeroplanes. Sport pilots spend a lot of unlearning exactly like this: the comfortable beliefs in common misunderstandings about sport pilot certificates, the real boundaries described in sport pilot limitations every student should know, and the fuel-system assumptions corrected in LSA fuel system mistakes pilots should avoid all fail the same way ChatOps myths fail — pleasantly, until checked against the manual. Check early, trust the record, and the myths never get airborne.
