Slack channel naming conventions for engineering teams
A prefix scheme for engineering Slack channels, with examples, Slack's own guidance on prefixes, description and archiving rules, and why names matter later.
The KnowWhyy team · · 8 min read
Open the channel browser in most engineering workspaces and you'll find #backend, #backend-team, #be-chat, #payments, #payments-v2, #payments-new-do-not-use and #tmp-sam-ana. Nobody knows which one is current, new hires join the wrong ones, and six months later nobody can work out which channel held the discussion about the payments rewrite.
A naming convention is one of the cheapest fixes in Slack. It takes an afternoon to agree on, costs nothing to follow, and decides whether your team's history can be found later. This guide gives you a prefix scheme for engineering teams, what Slack itself recommends, how to set up descriptions and canvases, when to archive, and how all of it helps later searches.
The rules Slack enforces
Before conventions, the hard limits. Slack's developer docs state that channel names "may only contain lowercase letters, numbers, hyphens, and underscores," and must be 80 characters or less. So #Payments Team isn't possible, and you'll need to choose between hyphens and underscores. Pick hyphens and use them everywhere.
Names can change later. Slack's article on renaming a channel says Workspace Owners and Admins can rename any public channel, and members can rename channels they manage. That means you can adopt a convention now and fix old channels gradually.
What Slack recommends
Ask your first question in minutes.
Create a workspace, connect a tool and choose what gets indexed. The free plan includes GitHub, Slack and Notion.
Slack ships with three default prefixes: #help, #proj and #team. Workspace Owners and Admins can keep them, delete them or add their own.
Each prefix has a description that tells members when to use it.
When creating a channel, members can choose from the list or type their own name. Prefixes appear only when creating channels in Slack on desktop.
Free workspaces can have up to six prefixes. Pro and Business+ workspaces can have up to 99.
If you delete or replace a prefix, existing channels keep their old names. Slack suggests asking members to rename them.
To add one on Free, Pro or Business+: on desktop, click Admin in the sidebar, hover over Edit workspace, click Channel prefixes, then Add Prefix. Enter the prefix and a description, then click Save. Enterprise plans use Tools & settings > Customize > Channel Prefixes.
Setting this up is worth doing even with only six slots on the free plan. The description shown at creation time does more to keep names consistent than a wiki page nobody reads.
A prefix scheme for engineering teams
Slack's list is a good start, but engineering teams need a few more. Here is a scheme that covers most of what an engineering org creates:
Prefix
Use for
Examples
Lifetime
team-
A team's home channel
#team-payments, #team-platform
Long-lived
proj-
Time-boxed, often cross-team projects
#proj-checkout-v2, #proj-postgres-16
Archive when done
inc-
One channel per incident
#inc-2026-11-06-checkout-errors
Archive after postmortem
ask- or help-
Questions for a team from outside it
#ask-platform, #help-data
Long-lived
alert-
Automated alerts, no human chat
#alert-payments-prod
Long-lived
deploy-
Deploy and release notifications
#deploy-api, #deploy-mobile
Long-lived
announce-
Low-volume, read-only announcements
#announce-engineering
Long-lived
topic-
Interest groups and guilds
#topic-frontend, #topic-security
Long-lived
ext-
Slack Connect channels with other companies
#ext-acme-integration
Archive when contract ends
social-
Non-work chat
#social-pets
Long-lived
Pick either ask- or help-, not both. If the rest of your company already uses Slack's default help-, use it in engineering too.
Naming rules that make the scheme work
Prefix, then general to specific.#team-payments-oncall, not #oncall-payments-team. The prefix groups channels and the next word narrows them down.
Use the same name as the repo or service. If the repo is billing-service, the channel is #team-billing or #proj-billing-service-migration, not #money-stuff. Matching names make it easy to find the channel from a PR, and the PRs from a channel.
Dates only where they mean something. Incidents get a date (YYYY-MM-DD) because there will be many of them. Projects don't, because #proj-checkout-v2-2026 turns into a lie when the project slips.
No personal names.#tmp-sam-ana should be a DM or a proj- channel.
No -new, -v2-real or -old. If a channel replaces another, archive the old one and say where the conversation moved.
Abbreviations only if they're in a glossary.#team-sre is fine if everyone knows SRE. #proj-bcm isn't.
Same rules for private channels. Private doesn't mean unnamed.
Put the scheme somewhere people will see it. A short version works well as the description of each prefix in Slack's settings, plus a pinned canvas in #announce-engineering:
Engineering channel names
-------------------------
team-<team> team home channel #team-payments
proj-<project> time-boxed project #proj-checkout-v2
inc-<yyyy-mm-dd>-<what> one per incident #inc-2026-11-06-checkout-errors
ask-<team> questions for a team #ask-platform
alert-<service>-<env> bots only #alert-payments-prod
deploy-<service> deploy notifications #deploy-api
topic-<interest> guilds and interests #topic-security
ext-<company> Slack Connect #ext-acme-integration
Rules: lowercase, hyphens, match repo/service names, no personal names,
no -new/-old. Every channel gets a description. proj- and inc- get archived.
Descriptions, canvases and bookmarks
A good name tells people which channel to open. The description tells them whether they're in the right place.
Slack's article on topics and descriptions explains the difference. Topics appear in the conversation header. Descriptions appear in channel details and when people search for channels on desktop. Both can be up to 250 characters. Since descriptions show up in channel search, they are worth writing carefully.
A description template that fits in 250 characters:
[What happens here]. Owner: @[person or group]. Not for: [what goes elsewhere, with channel]. Links: [repo or runbook].
For example:
Payments team coordination: planning, reviews, deploys. Owner: @payments-leads. Questions from other teams go to #ask-payments. Repo: github.com/acme/billing-service
For anything longer, use tabs. Slack's article on channel tabs says each channel can have up to 15 tabs for canvases, lists, workflows, messages, and folders of links and files, with up to 100 items or folders per channel. A useful setup for a team- channel:
A canvas with what the team owns, who's on call, and how to ask for help.
A folder with links to the repo, dashboards, runbooks and the team's decision log.
A workflow tab for common requests, if you use Workflow Builder.
For inc- channels, add the incident doc and the postmortem (see the incident postmortem template) as bookmarks as soon as they exist. People who arrive later can catch up without reading 300 messages.
Archiving rules
Old channels make the channel list noisy and lead people to post in dead places. Archive them, but don't delete them.
Slack's article on archiving or deleting a channel explains the difference. An archived channel is closed to new activity, but its message history "is retained and searchable on paid plans." A deleted channel is permanently removed, history included. Deleting a project channel throws away the record of why decisions were made.
By default, any member (except guests and Frontline Members) can archive a channel they belong to, and channels can be unarchived from Directories > Channels by filtering for archived channels.
Archiving rules by prefix:
Prefix
Archive when
proj-
Two to four weeks after the project ships or is cancelled, once the outcome is posted
inc-
After the postmortem is published and linked in the channel
ext-
When the partnership or contract ends
team-
When the team is dissolved or merged, after posting where its work moved
Anything with no message in 90 days
Review monthly, archive unless someone objects
Before archiving, post one final message: what happened, where the outcome is documented, and which channel takes over. That message is often what a future searcher needs.
One caveat for free workspaces. According to Slack's plans and features page, the Free plan gives 90-day access to message history, and content older than one year is permanently deleted. On Free, copy important outcomes somewhere durable before they age out.
How naming makes history findable later
Most of the value of a naming convention shows up months later, when someone needs to reconstruct a decision.
Search can be scoped. With predictable names you can search in:#proj-checkout-v2 "let's go with" or in:#inc-2026-11-06-checkout-errors rollback instead of searching the whole workspace. See how to find old decisions in Slack for more search modifiers.
Channel search works. Typing proj-checkout or inc-2026 in the channel directory lists every related channel, because names and descriptions follow a pattern. The Archived channels filter brings back the closed ones.
The context is in the name.#inc-2026-11-06-checkout-errors tells you what and when before you open it. #war-room-3 doesn't.
Channels line up with code. When channel names match repo and service names, it's easier to connect a Slack thread to the PR that implemented it.
You know what to index. Choosing which channels feed a search tool, an export or a compliance archive is easy when you can pick by prefix: all team-, proj- and inc-, skip social- and alert-.
Where KnowWhyy fits
A naming convention tells you where to look. KnowWhyy helps when you don't know where to look at all. You choose which Slack channels, GitHub repos and Notion pages it indexes, and a clean prefix scheme makes that choice quick. Then, in the KnowWhyy web app, you ask something like "why did we roll back the checkout deploy in November?" and get an answer that links to the specific threads, PRs and pages it used. DMs are never read, private channels are indexed only after you invite the app, and if the answer isn't in the sources it says so. See AI search for Slack.
The short version
Slack channel names are lowercase letters, numbers, hyphens and underscores, up to 80 characters. Use hyphens.
Start from Slack's recommended prefixes (help-, team-, proj-, announce-) and add engineering ones like inc-, alert-, deploy- and ext-.
Set prefixes up in Slack's admin settings so people see them, with a description, when they create a channel.
Give every channel a description of what it's for, who owns it and where other topics go.
Archive proj- and inc- channels with a final summary message. Don't delete them.
Match channel names to repo and service names so Slack history and GitHub history can be connected later.