Skip to content
Product

Choosing what your team hears about: Discord notifications per project

Give your team a Discord webhook, tick the events you care about and choose which projects get to speak.

RankMill
Drafted by an agent, edited in-house
Oct 29, 2026 · 8 min read

You can have RankMill post to a Discord channel when something happens in your team. You give the team a Discord webhook, tick the events you care about and choose which projects get to speak. Any project can also have its own list of events instead of the team's.

Here is how each of those choices works. At the end there are a few setups that suit a solo founder or an agency running several client sites.

A five-step flow: create a webhook in a Discord channel, give its URL to your team in RankMill, tick the events you want, choose which projects send notifications, then give a project its own list if it needs one.

Connecting a Discord webhook to your team

A webhook is a link Discord gives you so another app can post into one channel. You make it in Discord first.

  1. In Discord, open the settings for the channel you want the messages in.
  2. Go to Integrations and create a new webhook.
  3. Copy the webhook URL.

You need permission to manage webhooks on that server. If you do not see the option, ask whoever runs the server.

Then give that URL to your team in RankMill. The webhook belongs to the team, not to you. That fits how the rest of RankMill works: everything belongs to a team, so everyone in it shares the same projects, the same posts and the same notifications.

Two tips before you start. First, give RankMill a channel of its own. Something like #rankmill keeps the messages out of the way of real conversations, and it is easy to mute if you need a quiet week. Second, treat the webhook URL like a password. Anyone who has it can post into that channel.

The five events you can hear about

Once the webhook is in, you tick what you want to hear about. There are five choices.

  • A post written. The writer finished a post. It is ready for you to read, edit and schedule.
  • A post that failed. A write did not finish.
  • Topics found. A topic hunt came back with new topics for a project.
  • A post published. A post went out to the project's publish destination.
  • Any other run that failed. A run is one agent action. This covers failures that are not a post write, such as a topic hunt that did not finish.

You do not have to tick them all. A few messages you actually read beat a busy channel you learn to ignore.

Picking the events that matter

Each event earns its place for a different reason.

Failures are the ones to keep

A post that failed or a run that failed is the thing you are most likely to miss otherwise. Discord tells you something went wrong. The Activity view in RankMill tells you why, with a plain sentence for each failed run.

If a write failed, its credits stay spent. Writing the failed post again is free, though, so trying again costs you nothing.

Post written is for people who review

If you read every post before it goes out, this is your cue to open it. You can edit it by chatting with the editor, fix a word yourself in the block editor, then put it on the calendar.

Topics found is for people who approve by hand

Each project runs a topic hunt on its own cadence, and new projects start on weekly. A hunt comes back with five topics. Some may arrive with up to four questions the agent could not answer on its own.

If you approve topics yourself, this message tells you there is something to look at. If your team approves every new suggestion automatically, you may not need it, because the writing starts without you.

Post published is for peace of mind

A post can go out because you pressed Publish, because it reached its scheduled time, or because the project publishes automatically. The last two happen while you are busy with something else. This message tells you it happened.

Choosing which projects speak

Not every project needs a voice in Discord. You choose which projects send notifications, and a project you leave out stays quiet in the channel.

Its work carries on as normal. Its runs still show in Activity, and anything waiting on you still shows in Needs attention. You just do not hear about it in Discord.

Leaving a project out makes sense when:

  • it is a test project you use to try out writing rules or frontmatter
  • someone else on the team looks after it and watches it in the app
  • it is a project you only check in on now and then

Giving one project its own list

By default, every project that speaks uses the team's list of events. A project can have its own list instead.

Say your team list is failures only. That suits most projects. But your main site is the one you care about most, and you want to know each time a post on it goes live. Give that project its own list and tick post published.

Note the word instead. A project's own list replaces the team's list for that project. It does not add to it. So when you build one, tick the failures again too, or that project will stop telling you when something breaks.

It works the other way round as well. If one project hunts for topics daily and the team list includes topics found, that project can fill the channel. Give it its own list without topics found.

Why notifications never carry the post body

A notification tells you that something happened. It never includes the post itself. That works in your favour for a few reasons.

  • A Discord channel is often wider than your team. Servers have guests, old members, clients and bots. A post that is not published yet should not sit in a channel they can scroll back through.
  • Chat is a poor place to read a post. A full post in a channel is a wall of text that pushes everything else out of view.
  • The post lives in RankMill. That is where you can see its key points, edit it, look through its version history and publish it. A short message that sends you there is more useful than a copy you cannot act on.

What happens when Discord is down

A Discord that is down can never slow the actual work down. If Discord has a bad hour, posts still get written, topics still get found and scheduled posts still go out.

You might miss a message, but you will not miss the work. Activity has the full history of every run whenever you want to check.

Sensible setups for a solo founder and an agency

There is no single right answer. Here are a few starting points you can adjust.

A solo founder with one site

You are the whole team, so the channel is just for you. Pick based on how hands-on you want to be.

If you approve and review everything, tick:

  • topics found
  • a post written
  • a post that failed
  • any other run that failed

Topics found tells you to approve or decline. Post written tells you to read. The failures tell you to check Activity.

If you let RankMill run on its own, with automatic approval and a publish cadence filling your calendar, tick:

  • a post published
  • a post that failed
  • any other run that failed

Here you mostly want to know that posts are going out, and to hear quickly when one does not.

If your project uses a publish cadence with Human in the loop switched on, keep topics found ticked too. With that switch on, a topic on your calendar is not written until its questions are answered. A slot that passes unanswered gives the day back. A message when new topics arrive is a good nudge to go and answer any questions.

An agency looking after several client sites

Each client site is its own project, and everyone at the agency is in the same team. The channel can get busy fast, so start quiet.

Team list: a post that failed and any other run that failed. Let every client project speak, so whoever watches the channel hears about problems on any site.

Clients who sign off on every post: give those projects their own list with post written plus both failures. When a post is ready, the person looking after that client knows it is time to review it and send it over.

Clients who expect a steady rhythm: if a project publishes on a cadence, give it its own list with post published and both failures. You get a running record of what went out.

Internal and test projects: leave them out of the projects that speak.

If a client needs to be fully separate, you can keep them in a team of their own. You can be in more than one team and switch between them, and that team gets its own Discord webhook and its own ticks. It also has its own members and its own monthly credits, so only do this if that separation is what you want.

A good place to start

If you are not sure, tick the two failure events for the whole team and let every project speak. Run that for a couple of weeks.

When you catch yourself opening RankMill just to check on something, that is the event to add. Add it for the team, or give the one project that needs it its own list.

Share this post

Keep reading