The Gap Between Discord Membership and Real-World Participation

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

Your server says 3,412 members. That number records how many accounts once accepted an invite and never left, which is a tally of a past click rather than a description of a present relationship. Here is what sits between that number and nine people outside a bowling alley on Thursday.

The number at the top of the sidebar

Your server says 3,412 members. It has said something like that for a year, and it goes up more often than it goes down.

Now try to answer a small question with it. How many of those people will be standing outside a bowling alley at seven o'clock next Thursday?

The honest answer is that the number cannot help you. It was never measuring that, and it never claimed to.

A member count records one thing: how many accounts have, at some point, accepted an invite and not left. That is a tally of a past click, not a description of a present relationship.

It is closer to a visitor book than a guest list. Everyone who signed it was really there once, and none of them promised to come back.

What joining actually costs

Think about the moment somebody joins. They tap a link in a YouTube description, a Reddit comment or a friend's message.

There is no form. There is often no introduction, no approval, and nothing they have to say about themselves.

Discord's own data model reflects how thin that moment is. Look at the guild member object in Discord's developer documentation and the fields you get for a new member are joined_at, an array of role ids, an optional nickname, whether they are muted or deafened in voice, and whether they are still pending on membership screening.

That is the whole relationship. A timestamp and some flags.

Nothing in there is a commitment, because nothing was asked for. A member count is the sum of those timestamps, and a timestamp cannot be invited to anything.

Joining is an event that happened once. Attending is a promise about a Thursday. The sidebar only knows about the first one.

The two numbers Discord will actually give you

It is worth being precise here, because Discord does distinguish between two counts and most organisers only ever see one.

The guild documentation defines approximate_member_count as the approximate number of members in the guild. It also defines approximate_presence_count as the approximate number of non-offline members, and the same pair appears on the invite object, where both are returned when you ask for counts.

That second number is the one you have seen on an invite preview: 3,412 members, 289 online. The gap between them is the first honest thing anyone tells you about a server.

But look closely at what "online" means. It means the app is running and the status is not set to invisible.

It does not mean reading. It does not mean present. A phone in a pocket on a bus counts as online, and so does a laptop that has been open since Tuesday in a room with nobody in it.

So even the better number is measuring a process, not a person. Both counts are approximations of availability, and neither is an approximation of willingness.

The ladder, and why it is not a funnel

Most people picture this as a funnel. Members at the top, some percentage read, some percentage of those post, some percentage of those turn up.

That picture is comforting and wrong. A funnel implies one population getting filtered, where the people at the bottom are the most committed slice of the people at the top.

What you actually have is a stack of different populations that overlap only partly. The person who never posts and comes to every meetup is real, and so is the person who posts four hundred messages a week and would sooner move house than meet you.

Here is the ladder, named properly.

Member

An account that accepted an invite and has not left. Contains no information about attention, location, timezone or intent, and may have last opened the app in March.

Lurker

A member who still has the server in their list and occasionally sees it go bold. They are receiving the server, not reading it, and they are the largest group by a distance.

Reader

Somebody who genuinely reads channels and knows what is going on. Invisible to every metric you have, because reading leaves no trace anywhere in the product.

Poster

Somebody who writes messages. The first rung that produces evidence, which is exactly why organisers over-trust it.

Regular

Somebody with a recognisable presence: a name others know, an in-joke, a voice channel they sit in. A social relationship exists, and it is entirely online.

Attender

Somebody who will leave the house on a specific Thursday and be in a specific room. A separate population, drawn mostly but not only from the regulars.

Each rung is a different question, not a smaller slice of the rung above. "Do you read this?" and "will you be in Manchester on the 14th?" have almost nothing to do with each other.

The reason organisers keep getting burned is that they treat the top number as a base and apply a percentage to it. Five percent of 3,412 is 170, which sounds achievable, and it is a fantasy built on arithmetic that does not describe anything real.

Why most of your members are supposed to be passing through

Here is the part that reframes the whole problem. This is not a failure of your community.

A server is a public space. People wander in for one reason, get what they came for, and stay joined out of mild optimism rather than intent.

Somebody joined for a mod download link two years ago. Somebody joined during one game's launch week and has not thought about that game since. Somebody joined because a friend told them to and never found a reason of their own.

None of those people are failed community members. They are passers-by, and every good public space has far more passers-by than residents.

Think about a busy pub. Hundreds of people come through in a week, twenty of them are regulars, and six of them would come to the landlord's birthday.

Nobody thinks the pub is broken because 94 percent of its footfall would not come to a birthday. Servers get judged by a standard we would never apply to a physical room.

The mistake is not having lurkers. The mistake is putting the lurker number on a page next to the word "community" and then believing it.

What an admin can actually observe

Let us be fair to the tools. There are real signals available, and some of them are useful.

You can see message activity in channels, which tells you who posts. You can see roles, which tells you what people have opted into. You can see who is sitting in a voice channel right now, and the voice state object documented by Discord is unusually rich: which channel, muted or not, deafened or not, streaming, camera on.

Voice presence is the strongest available signal, because it costs something. Sitting in a voice channel for two hours is time you cannot spend elsewhere, and it is the closest thing a server has to being somewhere.

Roles come second, and only when they are self-assigned. A member who picked a regional role is telling you something they were not obliged to tell you.

Now the other column.

Look at the right column. Every entry there is something a guest list needs and a server will never hold.

This is not an accident or a gap waiting to be filled by a feature. A server that knew where all its members lived would be a surveillance product, and people would leave it.

The bot will not save you either

The usual next move is to install an analytics bot and count messages per member. It produces a lovely chart and it measures the wrong rung.

There is also a boundary worth knowing about. Reading member lists and presence is gated behind privileged gateway intents, which Discord describes as having additional access requirements because of the sensitive nature of the data, and which need approval once an app grows past a hundred servers.

Discord treats "who is in this room and are they online" as sensitive. It is worth noticing that the platform is more careful with this data than most organisers are with the conclusions they draw from it.

The Thursday that went wrong on arithmetic

Here is the failure, in the order it happens.

A moderator has 3,412 members and about 300 online at any time. They decide, sensibly, to be conservative and assume one percent of members will come to a local meetup.

One percent is 34. They book a room for 30 and put down a deposit.

The post goes up. It does well, thirty-odd reactions, a warm thread, several people saying this sounds great.

Nine people arrive. Two of them were not in the thread at all and heard about it in voice chat.

Nothing in that story was careless. The moderator applied a percentage to a number, and the number was not a population that a percentage could be taken of.

The correct starting figure was never 3,412. It was the number of people who live within an hour of that room, are free on a Thursday, and have enough of a relationship with someone attending to walk in alone. Nobody knows that number, and no dashboard contains it.

Five servers of a thousand, five different Thursdays

If member counts predicted anything, servers of the same size would behave the same way. They do not, and the differences are not subtle.

Same number in the sidebar. Five completely different answers.

What separates them is not size or engagement. It is how the members arrived, whether they arrived alone or alongside people, and whether being in the same physical place was ever plausible.

That is why the useful question is never "how big is the server". It is "what were these people doing when they joined".

The rung the sidebar cannot see

There is a specific population that breaks every model, and every organiser has met them.

They read everything. They know the in-jokes, they know who fell out with whom, and they have never posted a message in their life.

By every metric you have, they do not exist. They are indistinguishable from the person who joined for a download link in 2023.

And they are, quite often, the ones who come. Reading is a form of participation that produces no data, which means the strongest correlation with turnout is the one thing you cannot measure.

This is the same asymmetry described in the argument for letting people take part without joining the community first. Membership and participation are separate axes, and a product that only measures one of them will always mislead you about the other.

What to do instead of dividing by a hundred

The fix is not a better estimate. It is refusing to estimate from the wrong number in the first place.

1. Throw away the member count for planning purposes. Keep it for the invite page, where it does an honest job of signalling that the server is alive. It has no role in a booking decision.
2. Start from the people you can name. Write an actual list of individuals who might come. If you cannot get past twelve names, the event is a twelve-person event, whatever the sidebar says.
3. Ask a question only an attender can answer. Not "would you be interested in a meetup". Ask "are you free on Thursday the 14th, in this city, from seven". Vagueness produces vague answers and then you plan against them.
4. Make the answer cost something small. A named yes, given to a person, is worth ten reactions. Not because reactions are dishonest, but because they were never asked to mean this.
5. Make no a real option. If declining is awkward or invisible, people go quiet, and silence is the one answer you cannot book against. A fast no is a gift.
6. Confirm again two days out. The drop between the first yes and the second yes is the real number. Every experienced organiser learns this, usually by paying for an empty room once.

Step two is the one people resist, because writing twelve names feels like admitting the community is small. It is not small. It is a community of 3,412 people, twelve of whom will be at a bowling alley on Thursday, and those two facts are both true and completely unrelated.

Reactions, Interested, and other things that are not answers

There is a natural next move once you accept the member count is useless. Count something smaller.

So organisers count reactions on the announcement, or presses of the Interested button on a Scheduled Event. These are better, and they are still not attendance.

A reaction is a social gesture with no defined meaning. Six people put a thumbs-up on your post and you have no way to know which ones meant "I am coming", which meant "nice idea", and which meant "I am acknowledging that you posted".

The Interested button has the same shape with a friendlier name, which we take apart in detail in the piece on why Interested and attending are different numbers. It costs one tap, it is reversible without embarrassment, and nobody is ever asked to explain it afterwards.

The deeper problem is that all three of these signals share one property. They are cheap to give, which is exactly why they get given, and the cheapness is what makes them useless for a booking.

You need a signal that costs a little. Not much, and not an account signup, but enough that giving it means something to the person giving it.

Why this is worse on Discord than in a group chat

A WhatsApp group of nine has the same problem in miniature and copes fine. It is worth being clear about why.

In that group, everyone knows everyone's name. Everyone knows roughly where everyone lives, and there is a real social cost to saying yes and not showing up.

A server has none of those three. The name is a handle, the location is unknown, and the social cost of not appearing is close to zero because nobody would recognise you if they saw you.

Scale makes it sharper rather than different. This is the same wall that large Telegram groups hit when an event needs a real headcount, and the mechanism is identical even though the products are not.

The broader version of this argument, covering Discord's Scheduled Events and where they stop short, lives in the piece on why Discord is excellent for communities and complicated for offline plans. This article is the narrower half: what the top number is, and why it is not a base.

The honest version of the metric

None of this means member count is a bad number. It is a good number that answers a different question.

It answers: how many people have, at some point, thought this place was worth being in. That is genuinely worth knowing, and it is a decent proxy for reach.

What it cannot answer is anything with a date in it. Reach and commitment are different currencies, and the exchange rate between them is not a constant.

Read the last row and notice how narrow it is. One date, named people, an explicit answer.

Everything above it is a proxy, and every proxy in that table was designed for something other than attendance.

Where the guest list has to live

The conclusion is slightly annoying, because it means the server cannot do this job however you configure it.

A guest list needs three things a server structurally will not provide. A named list of specific people, an explicit yes or no from each, and a way to hold that without publishing anyone's real-world details to thousands of strangers.

The third one is the killer. The server's whole value comes from being open, and a guest list's whole value comes from being closed.

Those are not competing features. They are opposite requirements, which is why no amount of channel permissions or role fiddling resolves it.

The practical shape is to keep them apart deliberately. The announcement goes where reach lives, which is your server, and the answer goes where privacy lives, which is somewhere else with one link.

If you want the mechanics of running that second half, the article on tracking real attendance for a Discord event covers it, and the underlying principle is set out in the difference between a conversation and an event object.

Where Ontaym fits

This is the one section about our own product, and then we are done.

Ontaym holds the closed half. An event is a record at one address, and you drop that address into your announcement channel like any other link.

People answer yes or no without making an account, without joining anything, and without their details becoming visible to the rest of the server. You get a list of names attached to one date, which is the only number in this entire article worth booking a room against.

Your server does not change at all. The 3,412 stays where it is, doing the job it is good at, which is being a big open room people can wander into.

It is a narrow scope by design. A public ticketed event wants a ticketing platform, and a voice chat on Sunday wants nothing more than a Scheduled Event.

The thing worth remembering

A member count is a record of arrivals, and arrivals are the cheapest thing that happens in a community.

Everything expensive comes later and leaves no trace. Reading regularly, caring what happens, deciding a Thursday evening is worth spending on people you have only ever typed at.

Your server is not underperforming because nine people came instead of thirty-four. Nine people who had never met in person went to a bowling alley because of a thing you built, and the number in the sidebar had nothing to do with it.

Stop asking the sidebar how many people are coming. It does not know, it has never known, and it has been perfectly honest with you about what it counts.

Ask twelve people directly instead. The answer will be smaller, and it will be true.

Frequently asked questions