ChatOps: IRC Did It Before Slack Existed

In 2008, I was running a small hosting operation and we had an IRC channel — #ops on our private server — where the three of us coordinated everything. DNS changes, Apache restarts, customer escalations. At some point I wrote a Perl bot that could restart services via IRC commands. Type !restart apache web03 and the bot would SSH into web03 and run systemctl restart apache2. We didn't call it ChatOps. We called it "the bot." Five years later, GitHub would give this pattern a name, a framework, and a conference talk, and the rest of the industry would act like it was a new idea. It wasn't. It was just IRC operations automation with better marketing.

Before the Term Existed

Operations teams used IRC long before anyone coined "ChatOps." The pattern was natural. System administrators already lived on IRC. Their communication channel was already a terminal. Adding bots that could execute commands was a trivial extension of the existing workflow.

The earliest operations bots I encountered were simple notification relays. A Nagios monitoring system would send alerts to an IRC channel via a script. The channel became a dashboard. You watched the stream of messages and reacted when something went red. This was the 2000s equivalent of a wall of monitors in a NOC, except it fit in a terminal window and didn't require a physical room.

# Basic Nagios-to-IRC notification script (circa 2005)
#!/bin/bash
# Called by Nagios as a notification command
# Sends alert to IRC channel via netcat

IRC_SERVER="irc.internal.example.com"
IRC_PORT="6667"
IRC_CHANNEL="#ops"
IRC_NICK="nagios-alert"

HOST="$NAGIOS_HOSTNAME"
SERVICE="$NAGIOS_SERVICEDESC"
STATE="$NAGIOS_SERVICESTATE"
OUTPUT="$NAGIOS_SERVICEOUTPUT"

MSG="[$STATE] $HOST/$SERVICE: $OUTPUT"

(
  echo "NICK $IRC_NICK"
  echo "USER $IRC_NICK 0 * :Nagios Alert Bot"
  sleep 2
  echo "JOIN $IRC_CHANNEL"
  sleep 1
  echo "PRIVMSG $IRC_CHANNEL :$MSG"
  sleep 1
  echo "QUIT :Delivered."
) | nc -q5 $IRC_SERVER $IRC_PORT

From notifications to actions was a small step. If the bot could tell you that Apache was down on web03, why couldn't it also restart Apache on web03 when you told it to? The question answered itself. By 2010, many operations teams had bots that could execute a predefined set of commands: restart services, run deployment scripts, query monitoring systems, manage DNS records.

The key insight — which GitHub later formalized — was that doing operations work in a shared chat channel created an automatic audit log. Every command, every response, every decision was visible to everyone in the channel. New team members could read the scrollback and understand what had been done and why. Knowledge transfer happened passively, through observation.

GitHub and Hubot: The Origin

GitHub open-sourced Hubot in October 2011. Hubot was a CoffeeScript bot framework running on Node.js, originally designed for GitHub's internal IRC-based operations workflow. Jesse Newland's 2013 talk "ChatOps at GitHub" gave the pattern its name and its public definition: putting tools in the middle of the conversation.

Hubot's architecture was simple. Adapters connected it to chat platforms (IRC, Campfire, later Slack). Scripts defined response patterns: when a message matches a regex, execute a function. The function could do anything Node.js could do: HTTP requests, shell commands, database queries.

# Hubot script for IRC-based deployment (CoffeeScript)
# File: scripts/deploy.coffee

module.exports = (robot) ->

  # Deploy a branch to an environment
  robot.respond /deploy (\S+) to (\S+)/i, (msg) ->
    branch = msg.match[1]
    environment = msg.match[2]
    user = msg.message.user.name

    allowed_envs = ['staging', 'production']
    unless environment in allowed_envs
      msg.reply "Unknown environment: #{environment}. Valid: #{allowed_envs.join(', ')}"
      return

    if environment == 'production' and branch != 'main'
      msg.reply "Production deploys must be from main branch."
      return

    msg.send ":rocket: #{user} is deploying #{branch} to #{environment}..."

    # Call the deploy API
    robot.http("https://deploy.internal/api/deploy")
      .header('Authorization', "Bearer #{process.env.DEPLOY_TOKEN}")
      .post(JSON.stringify({branch: branch, env: environment, user: user})) (err, res, body) ->
        if err or res.statusCode != 200
          msg.send ":x: Deploy failed: #{err or body}"
        else
          result = JSON.parse(body)
          msg.send ":white_check_mark: Deploy #{result.id} started. ETA: #{result.eta}"

  # Lock deployments
  robot.respond /deploy lock (.*)/i, (msg) ->
    reason = msg.match[1]
    robot.brain.set 'deploy_lock', {
      user: msg.message.user.name
      reason: reason
      time: new Date().toISOString()
    }
    msg.send "Deploys locked by #{msg.message.user.name}: #{reason}"

  robot.respond /deploy unlock/i, (msg) ->
    lock = robot.brain.get('deploy_lock')
    if lock
      msg.send "Deploy lock removed. Was set by #{lock.user}: #{lock.reason}"
      robot.brain.remove 'deploy_lock'
    else
      msg.send "No deploy lock active."

GitHub's internal setup was extensive. Their Hubot instance (named "hubot" internally) could deploy any of GitHub's services, manage feature flags, query monitoring dashboards, page on-call engineers, manage DNS, and run one-off database queries. All from the #ops IRC channel. The culture was: if you can't do it from chat, build a Hubot script for it.

Deploy Bots: Shipping Code From a Chat Window

The deploy bot is the canonical ChatOps tool. The workflow:

1. Developer types hubot deploy main to staging in the #deploys channel.
2. Bot triggers the deployment pipeline (Jenkins, GitHub Actions, a custom script).
3. Bot reports progress to the channel: tests running, build complete, deploying, smoke tests passing.
4. Bot announces completion: "Deploy #4521 to staging complete. 3 minutes 22 seconds."
5. Everyone in the channel sees what was deployed, by whom, and when.

Etsy was another early practitioner. Their deploy bot — called "Deployinator" — was a web-based tool, but deployment status was broadcast to IRC. The channel served as the coordination layer: engineers announced their intent to deploy, other engineers acknowledged or objected, and the bot provided status updates. The social protocol — "I'm deploying X, anyone have concerns?" — was as much a part of the system as the code.

# IRC channel log during a typical ChatOps deploy session
# (reconstructed from memory, typical 2012-2014 pattern)

14:01  hubot deploy api-v2 to staging
14:01  Starting deploy of api-v2 (main@a3f8c21) to staging...
14:01  Running test suite... (est. 4 min)
14:05  Tests passed (312 passed, 0 failed). Building container...
14:06  Container built: api-v2:a3f8c21. Pushing to staging...
14:07  Deploy api-v2 to staging complete. 6m 12s.
14:07  Health check: https://staging.example.com/health → 200 OK
14:08  hubot graph staging cpu 1h
14:08  https://grafana.internal/d/staging-cpu?from=now-1h (CPU: 23%, normal)
14:10  staging looks clean. deploying to production.
14:10  hubot deploy api-v2 to production
14:10  hold — did you check the migration?
14:11  yes, migration ran on staging at 13:45, no issues.
14:11  ok, go ahead
14:11  Starting deploy of api-v2 (main@a3f8c21) to production...
14:15  Deploy api-v2 to production complete. 4m 31s.
14:15  Health check: https://api.example.com/health → 200 OK

Notice what happened at 14:10. Sarah asked about the migration. Marco answered. The exchange is in the channel log. If something breaks tomorrow, the team can search the logs and see that the migration was discussed and confirmed. This is the audit trail that ChatOps creates automatically, without anyone filling out a change management form.

CI/CD Integration: Build Notifications and Gate Approvals

Beyond deployment, CI/CD systems integrate with IRC for notifications and approvals. A webhook from Jenkins or GitHub Actions posts build results to the channel. Failures are visible immediately. Teams can react before the developer who broke the build even notices.

# Jenkins pipeline IRC notification (Groovy)
// In a Jenkinsfile
pipeline {
    agent any
    stages {
        stage('Test') {
            steps {
                sh 'make test'
            }
        }
        stage('Build') {
            steps {
                sh 'make build'
            }
        }
    }
    post {
        success {
            ircNotify('#builds', "Build #${BUILD_NUMBER} PASSED (${GIT_BRANCH}@${GIT_COMMIT.take(7)})")
        }
        failure {
            ircNotify('#builds', "Build #${BUILD_NUMBER} FAILED (${GIT_BRANCH}@${GIT_COMMIT.take(7)}) — ${BUILD_URL}")
        }
    }
}

// Helper function using a simple IRC webhook
def ircNotify(channel, message) {
    httpRequest(
        url: "http://ircbot.internal:8080/message",
        httpMode: 'POST',
        contentType: 'APPLICATION_JSON',
        requestBody: "{\"channel\": \"${channel}\", \"message\": \"${message}\"}"
    )
}

Gate approvals add a human-in-the-loop step. The bot announces that a deployment is ready and waits for an authorized user to approve it in the channel. This combines automation with oversight — the machine does the work, but a human makes the decision.

Lita, Errbot, and the Framework Ecosystem

Hubot inspired a generation of chat bot frameworks, each bringing the ChatOps pattern to different language ecosystems:

Lita (Ruby) was designed as a more maintainable alternative to Hubot. It uses a plugin architecture with a proper gem-based distribution system. Lita's IRC adapter connects to IRC networks using the Cinch library. The framework includes built-in authorization groups, making it straightforward to restrict commands to specific users.

# Lita handler for IRC ChatOps (Ruby)
# File: lita-deploy/lib/lita/handlers/deploy.rb

module Lita
  module Handlers
    class Deploy < Handler
      route(
        /^deploy\s+(\S+)\s+to\s+(\S+)$/i,
        :handle_deploy,
        command: true,
        restrict_to: :deployers,
        help: { "deploy BRANCH to ENV" => "Deploy a branch to an environment" }
      )

      def handle_deploy(response)
        branch = response.matches[0][0]
        env = response.matches[0][1]
        user = response.user.name

        response.reply("Deploying #{branch} to #{env}... (triggered by #{user})")

        result = deploy_service.trigger(branch: branch, environment: env)
        if result.success?
          response.reply("Deploy complete: #{result.url}")
        else
          response.reply("Deploy failed: #{result.error}")
        end
      end

      private

      def deploy_service
        @deploy_service ||= DeployService.new(config.api_url, config.api_token)
      end

      Lita.register_handler(self)
    end
  end
end

Errbot (Python) is the most actively maintained open-source ChatOps framework as of 2024. It has native IRC support, a plugin system with dependency management, built-in access control, and a web admin interface. Errbot's Python foundation makes it easy to integrate with the vast ecosystem of Python operations tools: Fabric, Ansible libraries, cloud provider SDKs.

# Errbot plugin for IRC ChatOps (Python)
# File: plugins/deploy/deploy.py

from errbot import BotPlugin, botcmd, arg_botcmd
import requests

class DeployBot(BotPlugin):
    """ChatOps deployment plugin."""

    @arg_botcmd('branch', type=str)
    @arg_botcmd('--env', dest='environment', type=str, default='staging')
    def deploy(self, msg, branch=None, environment='staging'):
        """Deploy a branch to an environment."""
        user = msg.frm.nick

        if environment == 'production':
            # Check if user is in the admin group
            if not self.is_admin(msg.frm):
                return "Production deploys require admin privileges."

        yield f"Deploying {branch} to {environment}... (by {user})"

        try:
            resp = requests.post(
                f"{self.config['API_URL']}/deploy",
                json={'branch': branch, 'env': environment, 'user': user},
                headers={'Authorization': f"Bearer {self.config['API_TOKEN']}"}
            )
            resp.raise_for_status()
            result = resp.json()
            yield f"Deploy #{result['id']} complete. Duration: {result['duration']}s"
        except requests.RequestException as e:
            yield f"Deploy failed: {e}"

Why IRC Was the Right Platform

ChatOps started on IRC for a reason. Several reasons, actually.

Text-native. IRC is a text protocol. Operations work is text work: logs, configs, commands, output. There was no impedance mismatch. A deploy bot's output looked the same as a human's message. The channel was a unified stream of human communication and machine output.

Always on. Operations teams already had IRC open 24/7. Adding a bot to an existing workflow costs nothing in terms of attention switching. Compare this to a web-based dashboard: opening a browser tab, navigating to a URL, clicking through an interface. The IRC command was faster.

Scriptable. Every IRC client can send arbitrary text to a channel. Integrating any tool with IRC required only the ability to write a line of text to a socket. No SDK. No API client library. No OAuth dance. Open socket, send PRIVMSG, close socket. This zero-friction integration is why IRC accumulated hundreds of bot integrations organically, without anyone designing an "integration platform."

Self-hosted. The IRC server was under the company's control. No third-party dependency. No SaaS outage preventing you from deploying during an incident. No data leaving the network. For operations work involving production credentials and server names, this mattered.

Slack replaced IRC for most companies' ChatOps by 2016-2017. The reasons were predictable: better UI, file sharing, search, mobile apps, and corporate procurement processes that preferred a SaaS vendor to a self-hosted IRC server. The ChatOps patterns survived the platform migration intact. The deploy bot moved from IRC to Slack. The notification webhooks pointed at Slack instead of IRC. The pattern was platform-agnostic; it just happened to be invented on IRC because that's where operations people already were.

Some teams still use IRC for ChatOps. Open-source projects on Libera.Chat. Security-conscious organizations that won't send operations data through a third party. Teams that value plaintext logs over searchable databases. The pattern doesn't require Slack. It doesn't require Hubot. It requires a shared text channel and a bot that can execute commands. IRC provides both with less overhead than anything else.