Running a Company from Slack: Build, Deploy, Change, and Business Alerts

At our startup, Slack isn't where we chat about work. It's where the work reports in. Builds, deploys, secret changes, test runs, release steps, and business events that need a human all post there. Nobody opens five dashboards to find out what happened today. They read a handful of channels.

Getting there was easy. Keeping it from turning into noise everyone mutes was the actual work.

TL;DR: post an event only when a person needs to know it or act on it. Give each kind its own channel, put the headline at the top level and the detail in a thread, and end every message with the next step. Stay quiet when things are normal, and make a failed post fail loudly where it matters.

What posts where

Event	Source	Channel
Build finished	CI workflow	Builds
Deploy started, checks, result	Deploy script	Deploys, one thread per deploy
Secret or config changed	Cloud audit log to a small function	Builds
End-to-end test verdict	A separate CI job	Tests
Release notes	CI plus an AI model	Releases
Release step done, next step	Release workflows	Releases
Stale pull requests and branches	Weekly job	Engineering
Business event that needs follow-up	Event queue consumer	One per event kind
AI assistant runs and findings	The assistant itself	Its own channel

Builds

Each build posts its result with the tag, who started it, the commit, and a color for pass or fail. It also includes the exact deploy command, ready to copy. If the build ran from a branch that's unusual for that environment, the message says so. If it kicked off a staging deploy on its own, it says that too.

Deploys get one thread each

A deploy opens one top-level message and puts everything else in its thread: preflight checks, the config diff, health checks, disk space, rollback commands. The channel reads as one line per deploy, and the detail is one click away.

The deploy never waits on Slack. Messages go into a queue with a single worker, so they stay in order and the deploy runs at full speed. When the process exits, it flushes what's left, so the final result always lands. And if a deploy finishes with the service still in maintenance mode, the last message is orange and carries the command to end it.

Secret and config changes

This one exists because a silent edit to a secret once broke a mobile build. Now every write to a secret, and every change to a function's environment, posts to Slack.

• The cloud audit log hands the event to a small function, which posts it.
• The message says what changed, who changed it, when, from where, and whether they used MFA. Key names only, never values.
• Environment changes are detected by comparing hashed snapshots, so no value is ever stored or posted. I wrote that part up in Catching Secret Changes the Audit Log Hides.
• Changes by CI are tagged as automation. Changes by the root account get an alarm title.
• Trying to turn the alerter off is itself an alert.
• If the Slack post fails, the function fails, retries, and a second alarm fires. A duplicate message beats a missing one.

Deploys are deliberately not watched here. They have their own channel, and reporting the same thing twice just trains people to skip both.

Test verdicts that can't get lost

The end-to-end suite posts one verdict per run: GREEN, RED, FLAKE, INFRA, or DID NOT RUN. That last one matters most. The run that never started is the one nobody notices.

The verdict comes from a separate small job, not the test runner, so it still arrives when the runner dies. If the post fails, that job fails. And the message is built with a JSON library rather than string concatenation, so a weird test title or branch name can't break the message or fake one.

Every release message ends with "Do:"

A release moves through steps: opened, on staging, QA passed, production PR ready, branches synced. Each step posts, and each post ends with Do: and the next action. Whoever joins halfway through knows where the release is and what to do next.

Release notes are written by an AI model and posted to the release channel, trimmed to fit Slack's single-block limit. If the notes fail to generate, that's a message too.

Business events

The platform posts the business events that need a person, each kind in its own channel: new rentals, payouts, bank account changes, admin actions waiting on someone. One more channel carries a stream of every event, with the full payload in the thread for debugging.

How it stays quiet

• Silent on success, where success is normal. A token check says nothing while the token works. It warns when it fails, at most once a day, and posts once when it recovers.
• Detail lives in threads. A colleague muted an early, chattier version of our AI assistant's run messages. Fair enough. Now the top line is short and the numbers sit in the thread.
• Nudges during working hours only. Reminders go out on weekdays in office hours, at most once a day, never twice for the same thing.
• Post only on findings. The nightly security check says nothing unless it finds something.
• Report the cleanup failing, not the cleanup. The weekly branch cleanup posts only when it breaks.