Discord Polls vs Actual Event Commitments

Discord Communities & Events August 22, 2026 13 min read By the Ontaym Editorial Team

Discord gives a server four ways to ask who is coming, and all four hand back a tally that looks identical. A poll, a reaction count, a bot roster and an Interested number mean four different things, and booking a table on the wrong one is how sixty becomes eleven.

Four ways to ask, four different answers

A server decides to do something in the real world. A bar, a Thursday, a table that needs booking for a number somebody has to say out loud.

Now watch how the question gets asked. There are four options sitting in the same app, and most organisers reach for whichever one is nearest.

Someone posts a native poll: "Who's up for Thursday?" Someone else drops a message with a tick emoji and says react if you are in. A moderator spins up a sign-up bot with a nice embed and a button. And the whole thing already has a Scheduled Event with sixty people pressing Interested.

All four produce a number. All four display that number in roughly the same way, as a tally next to a label.

They do not mean the same thing. Not close. One of them is not even measuring the right population.

That is the whole problem with counting people on Discord. The instruments look interchangeable and are not, and nothing in the interface warns you which one you just picked up.

What Discord's native poll actually is

Start with the poll, because it is the newest and the most misread. It is also very well documented, which makes it easy to be precise about.

Discord's own developer documentation for the poll object gives you the shape. The question text can run to 300 characters, each answer to 55, and there is currently a maximum of ten answers per poll.

You set a duration in hours, up to 32 days, and it defaults to 24. There is a flag called allow_multiselect that decides whether a person can pick more than one answer, and it defaults to false.

So far this is a perfectly sensible voting widget. The interesting parts are what happens to the numbers.

Results are visible while the poll runs, but the documentation is careful about them. It says results during voting may be imprecise, and that after a poll finishes a background job performs a final, accurate tally, which concludes when a field called is_finalized becomes true.

Read that twice, because it is unusual honesty from a platform. The live number on screen is an estimate, and only the closed poll gives you the real one.

Votes are also not anonymous in the way people assume. There is an endpoint for getting the list of users who voted for a specific answer, so who voted for what is retrievable data rather than a secret.

Two more behaviours matter for organisers. A poll message cannot be edited after creation, and the creator can end it early by expiring it, but nobody else can end somebody else's poll.

Put those together and the poll's real personality appears. It is a fixed question, asked once, answered in a window, tallied properly only at the end.

The poll is a good instrument. It is just measuring a Thursday that has not happened to anyone yet.

Everything the poll is good at, it is good at because it closes. Everything an organiser needs, they need after it closed.

What it cannot do, structurally

It cannot notice that reality moved. A vote cast on the 3rd is still sitting there on the 24th, looking exactly as fresh as it did the day it was cast.

It cannot be corrected in place either. Because the poll message is not editable, a change to the plan means a second poll, and now two counts exist in the same channel with no marker saying which one is dead.

And it cannot represent silence. Forty people saw the poll, nine voted, and the thirty one who did not are invisible in every reading of the result.

This is the same category error we take apart in the piece on the difference between saying you are going and answering a poll. Voting is a statement about your calendar, and attending is a promise about your behaviour.

The emoji tally, which is not an instrument at all

Reactions are the most used counting method on Discord and the only one that was never designed to count anything.

A reaction is a lightweight social gesture. It means acknowledged, or amused, or nice one, or yes, depending entirely on context and on the person tapping it.

When you write "react with a tick if you're coming", you are asking a general purpose gesture to carry a specific meaning for one message only. Some people read the instruction. Some react because the message was cheerful.

The tally then sits there looking like a headcount. It has a number and a list of names behind it, which is more than the poll gives you at a glance, and this is exactly why organisers trust it more than they should.

It also has a peculiar failure that the poll does not. Reactions are reversible in silence, so somebody who taps the tick in week one and quietly removes it in week three has changed your headcount without anybody being told.

We wrote a whole article on why emoji reactions make poor attendance records, and the Discord version has one extra wrinkle. Servers are full of custom emoji, so half the time the tick is a server in-joke that three people read as sarcasm.

The Interested button, and that word "subscribed"

Discord Scheduled Events are the closest thing in the app to a real event record, and they deserve credit for it.

The guild scheduled event object has a name, a description, a start time, an end time and a creator. It has a status field with four values, scheduled, active, completed and cancelled, and it has three entity types, one of which is external, meaning a place with an address.

It even has a recurrence rule that the documentation says is based on a subset of the iCalendar standard. That standard is RFC 5545, the specification behind every .ics file you have ever opened.

Then you get to the count. In the interface the member presses Interested, and in the data model that produces user_count, documented as the number of users subscribed to the scheduled event.

Subscribed. Not attending, not confirmed, not coming.

The word is accurate, and it describes a notification preference. Pressing Interested says please tell me when this starts, which is a completely reasonable thing for a person to want and a completely useless thing to book a table on.

The pillar article on why Discord is excellent for communities and complicated for offline plans takes the whole event object apart. For our purposes the relevant fact is narrow: the button has no opposite.

There is no Not Coming. So the sixty is a count of the enthusiastic, with no denominator, no declines, and no way to tell the difference between a person who forgot and a person who decided against it. That asymmetry is the subject of the article on Interested versus attending, and it is the single most expensive misreading in server organising.

Sign-up bots, and the part they genuinely fix

Now the fair bit, because most writing on this topic treats bots as a punchline.

A good sign-up bot closes a real part of this gap, and it is worth being exact about which part. It gives you three things none of the native options provide.

It gives the answer a name. A bot with Yes, No and Maybe buttons collects declines, and a decline is the piece of information the Interested button structurally cannot hold. Once No exists, silence becomes visible, because silence is now everyone in the role who pressed nothing.

It gives the record a shape. The good ones store a roster: who answered, what they answered, when, and often what they signed up for, which is why raid and scrim communities have used them for years without complaint.

It gives the answer a way to change. Press Yes, then press No a week later, and the embed updates. That is the thing a poll cannot do and a reaction can only do invisibly.

Some go further. Caps and waitlists, reminder pings a day before, per-role sign-up limits, a closing time, an export of the final list.

If your server runs regular events with the same people, a bot is genuinely the right answer and you should stop reading and go configure one. This is not a grudging concession. It is the correct tool for a recurring internal commitment inside a group that already knows each other.

Where the bot stops

The limits are also specific, and they are not about quality of engineering.

The record lives inside one server. Invite three friends from outside and they have to join the server, find the channel, and understand the bot's embed before they can say yes to a drink.

The record is also only as durable as the bot. Bots get rate limited, lose hosting, change ownership, break on a Discord API change, or get removed by a moderator tidying up integrations. When that happens the roster does not degrade gracefully, it vanishes, and the message it was attached to becomes a dead embed.

And the identity is a Discord account. That is fine until the plan involves a partner, a colleague, or the friend who left Discord in 2022, which is most plans that leave the house. There is more on that in the piece on tracking real attendance for a Discord server event.

The four instruments, side by side

Here they are against the only question that matters. Not how many people tapped, but what the tap actually promised.

Look down the fourth column. Three of the four cannot represent a decline, and a headcount without declines is not a headcount, it is a fan count.

That is why a server of four thousand can generate sixty Interested and eleven humans. Nobody was dishonest. The instrument only had one direction.

How each one goes stale

Every one of these numbers is most accurate on the day it is collected. What differs is how it rots, and rot patterns are worth knowing because they tell you when to stop trusting a figure.

The Interested row is the one to sit with. It is the only signal here that gets less accurate as it gets bigger, because it is a running total of everyone who ever fancied the idea.

Sixty is not sixty people who will be there. Sixty is sixty moments of enthusiasm, spread over five weeks, from people in eleven time zones.

Some words worth keeping apart

Most of the confusion here is vocabulary. These four terms get used as if they were synonyms, and keeping them apart fixes more than any tool change.

Vote

A ranked preference between options you were given, valid at the moment it was cast. It answers "which", never "will you".

Reaction

A social gesture with no fixed meaning, borrowed for the evening to mean something specific. Reversible without notice and unprovable afterwards.

Subscription

A request to be told when something happens. Discord's own documentation uses this word for what the Interested button produces, and it is the honest one.

Commitment

A statement made to a named person that they may plan around. It is the only one of the four that can be broken, which is exactly what makes it useful.

Notice that only the last one has a cost attached. That cost is not a flaw in the design, it is the entire mechanism.

A signal you can give away for free tells you almost nothing. A signal that makes you pause for half a second before you tap it tells you a great deal.

What an organiser can safely conclude

Here is the practical translation. Take each number and write down what it actually licenses you to do.

A poll result licenses you to pick a date. It does not license you to book anything, because voting for Thursday and being free on Thursday in six weeks are different claims.

A reaction tally licenses you to feel encouraged. Treat it as a temperature reading, and never quote it to a venue.

An Interested count licenses you to run the event at all. Sixty is a real signal that the idea has an audience, and that is genuinely worth knowing before you spend a Saturday planning it.

A bot roster licenses you to book for the yeses, minus a fade. Even a proper yes decays, so the roster is a floor and a ceiling rather than a number.

Everything else licenses you to ask again. That is not a failure of the tools, it is the correct response to a signal that was never a commitment.

A sequence that works on a real server

The four instruments are not rivals. They are stages, and the mess starts when a server uses one of them to do all four jobs.

1. Ask the room, with a poll. Two or three dates, a short duration, and multiselect on so people can say which ones work rather than which one they prefer. Close it on purpose so the tally is final rather than approximate.
2. Announce the winner as a decision, not a result. The poll chose the date. Say the date, in a sentence, so nobody has to interpret a bar chart to find out what is happening.
3. Create the Scheduled Event, and read Interested as reach. It is the best notification mechanism in the app and the worst headcount. Use it for the first job and never the second.
4. Collect the actual yeses somewhere with a "no" in it. A sign-up bot inside the server, or a link outside it if anybody involved does not live in that server. This is the step people skip, and it is the only step that produces a number.
5. Reconfirm two days out, once, by name. Not another poll. A short message that says here is the list I have, tell me if you are on it by mistake, because a stale yes is more expensive than a no.
6. Write down what turned up. Compare the roster to the room. Two events of that and you will know your server's real conversion, and you will stop guessing forever.

Step six is the one nobody does and the one that pays off longest. Every server has a stable ratio between its enthusiasm and its attendance, and you only need to measure it twice to start booking accurately.

Why the interface makes this hard on purpose, sort of

None of this is Discord being careless. Each of the four is well built for the job it was built for.

Polls exist because servers argue about things and needed a way to settle them. Reactions exist because a thousand people cannot all reply. Interested exists so a stream announcement can reach the people who wanted it, and bots exist because Discord left a platform open enough for communities to build what they needed.

The trouble is that they all render as a number next to a label. Visual sameness implies semantic sameness, and your brain believes the layout before it believes the documentation.

There is a similar effect across every chat app, and we covered the general version in the difference between an RSVP and a group chat reaction. Discord's version is sharper only because it offers four of them at once.

The other thing worth naming is social. A Discord server is a low obligation space by design, which is precisely why people love it.

You can lurk for a year without anyone minding. That norm is a feature of the community and a problem for the organiser, because a place where nothing is expected of you produces signals that expect nothing of you.

The scale problem underneath all of it

There is one more reason the numbers behave strangely, and it has nothing to do with buttons.

A poll asked in a channel of four thousand is answered by whoever was awake. A poll asked in a group of nine is answered by nine people who all know each other, and social pressure quietly does the work the software cannot.

So the same instrument is far more accurate in a small room. That is why organisers who move from a friend group to a big server feel like the tools got worse, when what changed is that the crowd stopped being accountable to them.

Big servers need an explicit yes precisely because they cannot rely on the implicit one. The comparison in Discord events versus dedicated event pages is really about this: at what size does the informal signal stop working.

The answer is somewhere between thirty and a hundred, and it depends on how much of the room knows each other by name. Below it you can count reactions and be roughly right. Above it you are reading tea leaves with excellent formatting.

Where Ontaym fits

This article exists because Ontaym is built for the fourth column of that first table, and only that column.

An event is a record with one address. It holds the current time, the current place, and each person's answer, including the ones who said no, because a no is information.

Guests answer at a link without joining the server, installing anything, or handing their phone number to everyone else on the list. That is the specific gap a sign-up bot cannot close, since a bot's roster is a Discord roster by definition.

The conversation stays exactly where it is. Your server keeps the channels, the roles, the in-jokes and the voice chat that never empties, and the plan stops being something the channel has to remember.

If everyone involved is already in your server and you run the same event every fortnight, a bot is probably the better answer. That is an honest boundary, and pretending otherwise would waste your afternoon.

The one thing worth keeping

Before you trust any number on Discord, ask what a person had to give up to produce it.

A vote costs a tap and expires with the question. A reaction costs nothing and means whatever the reader decided. Interested costs nothing and buys you a reminder.

A yes with your name on it, given to a person who will notice if you do not appear, costs something. That is the only one you can put on a booking.

Four instruments, one dial each. The organiser's whole job is knowing which one they are holding.

Frequently asked questions