How to Send Product Updates to a Discord Community Automatically: The Three Lane Feed

Send product updates automatically by first sorting them into three lanes. Announce is loud, rare, and watched by a named human for thirty minutes. Update is batched daily with replies read each morning. Signal is opt-in behind a role and openly unmonitored. Every automated message names who is affected, what to do, and who answers today.

---

Pick the lane before you connect the webhook

The technical part of sending product updates to a Discord community automatically takes an afternoon. A webhook, a formatting template, a schedule. The decision that determines whether it works is upstream of the tooling: which updates go where, how loudly each one arrives, and who is responsible for what members say back. Get that wrong and the automation reliably makes things worse, because you have industrialised the act of talking without changing your capacity to listen.

Why automated posts fail in a community

A status page is a broadcast surface. A community is a room. Posting the same content into both, with the same assumptions, is the underlying error. When a message lands in a room, people reply to it. They ask whether the fix covers their case, they report that it did not work, they ask when the other thing is coming. Those replies are the entire reason to post in a community rather than send an email.

An automated post with replies enabled and nobody reading them is the most expensive silence in your product. Members interpret it as an answer.

Lane one: announce

Contents: incidents, breaking changes, planned downtime, anything requiring member action. Loudness: this is the only lane allowed to notify everybody, and only when the reader has something to do. Staffing: automation posts it, and a named human is present in the room for the next thirty minutes. Not on call. Present, watching the channel, ready to answer the first three questions, which are almost always the same three questions. The thirty minute window matters more than the message copy. Members judge an incident by whether a human appeared, and the appearance has a short half life.

Lane two: update

Contents: releases, fixes, new documentation, changes worth knowing about but requiring nothing today. Loudness: no broad notification. Members who want it can follow the channel themselves. Staffing: the owner reads replies once each morning, within a stated window. Say the window out loud in the channel description so expectations match reality. Batch this lane. One post a day carrying five changes outperforms five posts carrying one change each, because the first is a habit members can form and the second is noise they will eventually mute.

Lane three: signal

Contents: build results, deploy notifications, the raw change feed, anything a small number of technical members find useful. Loudness: behind a role, opt in, invisible to everybody else. Staffing: none, stated plainly. This channel is automated and not monitored. Post questions in the help forum. A written non-promise is honest and costs you nothing. An implied promise you fail to keep costs a member. Hiding this lane behind a role is not about secrecy. It keeps your general population from reading a firehose as evidence that the room is chaotic.

The anatomy of an automated post

Most automated messages carry one field: what changed. Four fields make the difference between a notification and a piece of support.

• [ WHAT CHANGED ] Import now accepts files up to the new size limit
• [ WHO IS AFFECTED ] Teams on the paid plan using bulk import
• [ WHAT TO DO ] Nothing. Existing imports continue to work.
• [ WHO ANSWERS ] Priya is in this channel until 6pm UK time Optional fifth field for the announce lane only:
• [ NEXT UPDATE ] Within 30 minutes, or sooner if resolved The fourth field is the one that changes member behaviour. A name converts a broadcast into a conversation with a known counterpart, and it takes one variable in your template to include it. The third field prevents the most common support load after any release announcement, which is a wave of people asking whether they need to act.

Keep a registry

Every automated channel needs a row in a document your support team can read.

• Channel name. Where the messages land.
• Source system. What actually posts here, named specifically enough that somebody can find it.
• Human owner. One person, not a team.
• Reply expectation. Immediate, daily, or none, matching the lane.
• Escalation. Who gets contacted when the feed breaks or floods. Why orphaned webhooks are so common in fast growing communities They are created during a launch by whoever is closest to the problem, they work perfectly for months, and the person who made them changes roles. Nothing fails, so nothing prompts documentation. Then a feed floods at 2am or goes silent during an incident, and the room contains nobody who knows which system is responsible. The registry costs twenty minutes to create and is almost always assembled during the first outage instead.

Muting is permanent

The most damaging outcome of an over-notifying feed is not annoyance. It is that a member mutes the server and never unmutes it. Every notification you send spends credit against the one message you will genuinely need them to read. Incidents, migrations, and price changes all depend on that credit being intact. So the rule is conservative by design. Loudness matches required action. If the reader has nothing to do, the message can wait for the daily batch, and your feed stays trusted for the day it matters.

Incidents: the room is not the status page

During an incident, members do not want your status page language. They want acknowledgment in the room, in words that sound like a person, within a short and stated interval of the status page update. Write the timing rule down before you need it. Something like: community post within five minutes of any status page change, a follow up every thirty minutes even when there is nothing new, and a plain language summary once resolved. The follow up with nothing new is the one teams skip and the one members remember. Automation can carry the first message. It cannot carry the third, because by then people are asking specific questions about their own accounts, and that is where a human earns the trust the whole system exists to protect.

What to measure

Three numbers, reviewed monthly. Unanswered reply rate on automated posts tells you whether the lane staffing is real. Opt out rate on your signal role tells you whether that lane is calibrated. Time from status page change to community post tells you whether your incident process includes the room at all, and it is usually the number that surprises people most.

Where this sits in the larger system

A feed is one layer, and it is the layer most likely to be built before the layers that support it. Underneath it sits the rest of the build: channel and role architecture that decides who can see which lane, onboarding that tells a new member which channel to follow, support routing with a written escalation path from a public reply to a private ticket, moderation coverage across the hours members are awake, an engagement rhythm somebody owns, and reporting that connects response behaviour to retention. Automation multiplies whatever those layers already produce, in both directions. Open your server, list every channel a machine posts into, and write the owner's name beside each one. The blanks are your work for this week.

*Automation is generous with output and indifferent to obligation. The obligation is still yours. More at *danieljeong.org