Slack bug report: a template, a severity guide, and a shortcut

A Slack bug report usually arrives as a single line. In our #support channel it reads something like "hey is checkout broken? a customer says it won't go through", with nothing about the browser, the account, the error, or when it happened, so whoever picks it up spends the next half hour messaging back and forth before they can reproduce it, and most of that time goes to waiting for replies.

By Slack standards that report is perfectly normal, because people write short messages in chat and no amount of process will change that. What we changed instead is how the report gets turned into something an engineer can work from. This guide covers what a good bug report contains, a template you can pin today, a severity guide, and how we turn any thread into a complete report with one reaction.

How to write a good Slack bug report

A good Slack bug report gives an engineer five things:

1. What happened, in the reporter's words.
2. What they expected to happen instead.
3. Steps to reproduce, even rough ones.
4. Where it happened: the page, the account or workspace, the browser or device.
5. Evidence, such as a screenshot, an error message, a link, or a timestamp.

If you want a template to pin in your bug channel, this is the one we used:

What happened:
What I expected:
Steps: 1. 2. 3.
Where (URL, account, browser):
Screenshot / error:

Why bug report templates get ignored

We pinned that template for about two months, and while the engineers used it, almost everyone else ignored it, which I understand. Someone in sales who has just come off a call with an annoyed customer is not going to stop and fill in five labeled fields, so they paste what the customer said and move on, and even that short message is a useful signal. In our experience, asking non-engineers to write better bug reports mostly leads to fewer bug reports.

The missing details usually turn up anyway, spread across the thread: the customer's email appears in the second reply, the screenshot arrives ten minutes later, and someone mentions in passing that it only happens on Safari. What's hard is collecting all of it into one place before the thread scrolls away.

Turn any Slack thread into a complete bug report

With Viably, anyone in the channel can react to the message with 🐞. Viably reads the whole thread, including the replies and screenshots that came after the first message, and writes the report an engineer wants to read:

• a title short enough for an issue tracker
• a description with steps to reproduce, expected versus actual behavior, and any links from the thread
• a severity of low, medium, high, or critical, based on what the thread says about impact

The issue card posts back into the thread so the reporter can see it was picked up. If you've connected GitHub, the card offers to create the issue in a repo you pick, with the severity as a label and a link back to the Slack thread, and the screenshots come along through private storage that only workspace members can open.

A checkout report like the one above, with a few replies under it, turns into something like this:

Checkout fails for EU cards on Safari after 3DS prompt Severity: high

A customer on Safari 17 reports that checkout hangs after the 3D Secure prompt closes. The payment is not created. Reported for a Visa card issued in Germany. Expected: order confirmation page. Actual: spinner, no error. Screenshot attached.

An engineer can start reproducing from that, and nobody had to rewrite the original message or chase the reporter for details. Without AI configured, the raw thread text becomes the issue body, so you still get the tracked issue, only without the generated title and severity.

A severity guide for Slack bug reporting

The AI suggests a severity and anyone can change it. These are the rules we follow, and because the model reads the same cues, its suggestion and the human call usually agree:

Collecting bug reports from customers

Some of the most useful bug reports come from customers who never touch Slack. If your support form or help desk can send a webhook, Viably's webhook relay posts each submission into a channel as a message the team can react to, and the same 🐞 reaction turns it into a tracked issue. That puts customer reports and internal reports in one queue with one severity scale.

Habits that keep Slack bug reporting useful

A few habits made the biggest difference for us:

• Keep one channel for bugs. Reports scattered across ten channels get missed, so we route everything to #bugs and cross-post from elsewhere.
• Add to the thread instead of replying "+1". If you're seeing the same bug, reply with what you saw and let one person file it, since everything in the thread becomes part of the report.
• Close the loop in the same thread. When someone resolves the issue, the card updates in place and the person who reported it sees the outcome where they raised it.

Once reports are coming in cleanly, the next step is tracking them to done. I cover owners, status, and the GitHub sync in Slack issue tracking.

Frequently asked questions

Add Viably to Slack and your next one-line bug report becomes one an engineer can pick up straight away. The issue tracking docs cover setup and GitHub sync.