What Happens When a Telegram Event Has Hundreds of Participants?

Telegram Event Coordination August 22, 2026 15 min read By the Ontaym Editorial Team

Telegram's ceilings are so high that organisers genuinely try to run events for hundreds of people out of a group chat. It works surprisingly well until somebody outside the community, usually a venue, asks for a number nobody can produce.

The venue asked for a number

A Telegram group runs a language exchange in a European city. Four thousand members, a genuinely lovely community, and a bar that has agreed to host the summer meetup.

The bar manager asks one question. How many people are coming?

The organiser looks at the announcement. Three hundred and ten reactions, ninety one poll votes, forty two replies saying some version of "count me in".

None of those is the answer. The manager needs a figure to staff a bar with, and the chat can produce four numbers, all of them wrong in different directions.

So the organiser guesses. They say a hundred and fifty, because that felt brave but not reckless, and then they do not sleep properly for a fortnight.

This is the part of large-scale community organising nobody writes about. Not the noise, not the mess, but the specific moment where a real business needs a real integer and you are holding a chat log.

Telegram is the platform where people actually try this

Most chat apps make an event of three hundred people impossible by accident. The room is too small, so nobody attempts it.

Telegram removes that excuse. According to Telegram's own FAQ on groups and channels, a group can hold up to 200,000 members, and channels take an unlimited number of subscribers.

The API documentation on channel and group types is more precise. A basic group caps at 200 members, becomes a supergroup above that, and a supergroup can be converted to a gigagroup where the participant limit is removed entirely.

That ceiling changes organiser behaviour, and it is the whole reason this article is different from the same argument about a crowded WhatsApp group. On a platform capped in the low thousands, a big meetup is obviously a stretch.

On Telegram, the room is bigger than any venue you could book. So people try, and they get surprisingly far before anything visibly breaks.

Then it breaks all at once, roughly a week before the date, when somebody outside the chat needs a commitment.

What breaks first, in order

Growth does not degrade a coordinated event evenly. Specific things fail at specific sizes, and they fail in a predictable sequence.

Around thirty, the replies stop being countable

At twenty people, "reply if you are coming" works fine. You scroll up, you count, you have a list.

At thirty five it takes real concentration, and at eighty it is a job. Worse, the replies are interleaved with jokes, questions and one person asking whether the venue is wheelchair accessible.

The organiser starts copying names into a notes app. That is the moment a human quietly became the database, and everything after this point is that human working harder.

Around a hundred, the announcement stops being read

A single message in a busy group has a shelf life measured in hours. Members who muted the group, and in a group of thousands most of them have, will see it whenever they next open the app.

Telegram has a genuinely good answer here, which most organisers underuse. The FAQ notes that when you pin a message, all members get a notification even if they muted ordinary messages from your group.

That is a real broadcast channel hiding inside a pin. It is also single use in practice, because pinning the same announcement three times to force three notifications is how communities lose members.

Around two hundred, the private messages arrive

This is the failure organisers never predict. As the crowd grows, the number of people who will not ask a question in front of two hundred strangers grows faster.

So they message the organiser directly. Is there parking, can I bring my flatmate, what time does it actually start, is this suitable for beginners.

Each one is reasonable. Together they are an unpaid support desk, and the answers live in fifty separate conversations where nobody else can see them.

Around three hundred, the plan becomes a liability

Below a hundred, being wrong is embarrassing. Above a few hundred, being wrong costs money, because you have booked something.

A deposit, a room hire, a caterer, a coach. The organiser is now personally exposed to the difference between the number in the chat and the number on the night.

The chat scales beautifully right up to the point where somebody has to sign something.

A member count is not an attendance number

The single most expensive confusion in large community organising is treating these as related quantities. They are not even the same kind of fact.

Membership is a historical record of a tap. Somebody joined this group at some point, possibly two years ago, possibly to ask one question about a train timetable.

Attendance is a claim about the future made by a specific person about a specific date. It has an owner, an expiry and a truth value.

Between those two sit several other numbers that also are not attendance, and the whole problem is that all of them are visible while attendance is not.

Notice the direction of travel. Each row is cheaper to produce than the row below it, and every cheap signal inflates.

Organisers know this instinctively, which is why they develop private conversion rates. Halve the poll, quarter the reactions, add ten for the ones who never say anything and turn up anyway.

That folklore is not stupid. It is what you build when the quantity you need is genuinely unmeasurable with the tools in front of you, a problem the gap between a Telegram community and an actual meetup creates in every community that gets big enough.

Why a venue needs a figure a chat cannot give

It helps to understand what the number is for, because organisers often think the venue is being fussy. The venue is not being fussy.

A headcount is an input to at least five separate decisions, each made by a different person on a different deadline. Staff rota, stock ordering, room layout, safety capacity, and whether the booking is even accepted.

Some of those decisions are irreversible days in advance. Food gets bought, staff get scheduled, a second room gets held or released.

And the number has a shape the chat cannot express. A venue does not want an estimate, it wants a commitment with a tolerance, something like a hundred and twenty confirmed with room for thirty more.

The last row is the one that quietly damages communities. Venues remember which organisers overpromised, and the good rooms stop returning calls.

The logistics that only exist at this size

Small events have one logistic: be there at eight. Large events have a set of problems that simply did not exist at twelve people, and none of them have a chat-shaped solution.

Arrivals spread over an hour

Twelve people arrive within ten minutes of each other, because they are watching each other's arrival in the thread. Three hundred people arrive across a full hour, sometimes more.

That changes the physical event. You need someone at the door for sixty minutes, not five, and the people who came at seven are already deep in conversation when the seven forty five group walks in.

Telegram can help with the mechanics of a single meeting point. The blog post introducing improved live locations added proximity alerts that notify you when someone is close, which is genuinely useful for finding two friends outside a station.

It does nothing for three hundred. You cannot watch three hundred dots, and the door problem is not a finding problem, it is a staffing problem.

Capacity that has to bite

A room holds what it holds. Above that number you are not being popular, you are being unsafe, and somebody is going to be turned away at the door.

A group chat has no concept of a cap. There is nowhere to put "this closes at a hundred and eighty" that actually closes at a hundred and eighty.

Organisers improvise by announcing the cap and hoping. Then they spend the last week telling latecomers privately that it is full, which is both miserable and unverifiable, because the person being turned away can see two hundred people still chatting away in the group.

Waitlists, which are worse than they sound

Once there is a cap, there is a waitlist, and a waitlist is an ordered queue with dependencies. Position four gets in only if three people above them drop out.

Try holding that in a chat. The order lives in message timestamps, the drop-outs arrive as private messages, and every promotion needs a personal note to a specific human.

Most organisers abandon the waitlist about two days before the event and just let people turn up. Which works, right up until it does not.

Sub-groups, hosts and things that need assigning

At scale an event usually has internal structure. Six table hosts, two people on the door, a group going for food afterwards, a language beginners corner.

Assigning those is a small piece of state per person. The chat can announce them once and then loses them, so the organiser ends up maintaining a document that only they can see.

The no-show number nobody can calculate

Ask an experienced community organiser what their no-show rate is and you will get a confident figure. Ask two organisers and you will get two different confident figures.

Here is the honest position. In this setup, the no-show rate is not merely unknown, it is undefined, because the denominator does not exist.

A no-show rate is the proportion of people who committed and did not appear. That requires a list of commitments, with names, made before the event.

A group chat produces no such list. There are reactions, votes and replies, and each of those is a different population with a different meaning.

So whichever ratio you pick, you are dividing by a number you invented. The result feels like measurement and is closer to superstition.

There is a second reason the figure is unstable even where people do try to track it. No-show behaviour is not a constant of human nature, and it moves with things the organiser controls.

• Whether the commitment was public or private
• Whether anything was paid, even a token amount
• How long ago the yes was given
• Whether a reminder arrived, and how close to the day
• Whether the person believes they will be missed
• The weather, which beats all of the above

That last one is not a joke. Any organiser who has run an outdoor event knows the forecast is a bigger variable than anything in their planning.

Which means the useful move is not finding the right percentage. It is building the list that would make a percentage meaningful, and then noticing what your own group does over three or four events.

Until then, the honest sentence to give the venue is a range with a floor you can defend. Not a point estimate dressed up as knowledge.

Reaching everyone, not whoever happens to be looking

The other half of large-scale coordination is delivery. A change at this size is not information, it is an operation.

Consider the ordinary case. The venue moves the start from seven to eight, four days out, and three hundred people need to know.

In a chat, you post it. That reaches the people who open the app in the next few hours and have not muted the group, which is a minority and not a knowable one.

Telegram gives you real tools here, and they are better than the alternatives. A pinned message notifies even muted members, and a channel keeps the announcement clean and unburied, which is why the channel versus group question comes up in every community that grows past a few hundred.

Scheduled messages help too. Telegram's post on scheduled messages and reminders explains that holding the send button lets you set a message to go out at a specified future time, which means the day-before reminder can be written while you still have the energy.

All of these are broadcasts. Every one of them pushes information outward and none of them tells you who received it.

The last row is the only one where the reader can pull rather than wait to be pushed. That distinction matters most for people who joined late, which at three hundred is always a large group.

It also solves the question that eats the organiser's evening. When somebody asks what time it starts, the answer is a link, not a retelling, and this is exactly the habit behind keeping one source of truth for a group event.

What organisers of this size actually do

Communities that run big events repeatedly do converge on a method. It is not elegant, and it mostly works, and it is worth being honest about both halves of that.

1. Announce in a channel, discuss in the group. The announcement stays legible because nobody can reply over it. This works well and costs you the ability to hear anything back in the same place.
2. Run a poll for the date, then never trust it again. Polls are excellent at closing one question at one moment. They are a snapshot of preference, which is why a vote and an actual attendance number keep coming apart.
3. Collect real names in direct messages or a form. This is the step that produces something usable, and it is also the step that leaks the event out of Telegram into a spreadsheet. It works, and it puts one person in the middle of everything.
4. Appoint a second admin as a router. Someone answers the private questions so the organiser can do the actual event. Effective, and it doubles the number of people holding facts in their head.
5. Pin one message and keep it current. Edit rather than repost, so the pin does not multiply. Good discipline, and it decays the moment two pins coexist.
6. Schedule the reminder in advance. Write the day-before message a week early and let it send itself. Genuinely useful, and it still only reaches whoever is looking.
7. Guess the number, then pad it downward. Tell the venue a figure you can defend rather than one you hope for. This protects the relationship and guarantees you are wrong on purpose.

Read that list again and notice what every step has in common. Each one is a person compensating for a missing record, and the compensation gets more expensive as the number grows.

That is not a criticism of the organisers. It is a description of doing database work by hand in front of an audience.

The objections that come up every time

Anyone who has run a large Telegram community will have replies ready. All three of these are reasonable and none of them survive contact with a deposit.

"A bot already handles our RSVPs"

Bots are the strongest answer available inside Telegram, and a good RSVP bot genuinely does produce a list. If yours works, keep it.

The limits are worth naming anyway. The list lives inside one bot in one platform, guests need a Telegram account to be on it, and the person who set it up is now a dependency the community cannot easily replace.

"Big communities are supposed to be loose"

For a walk in a park, absolutely. Turn up, or do not, and nobody has lost anything.

The argument only fails when something has been booked. The moment there is a deposit, a caterer or a legal capacity, looseness stops being a philosophy and starts being a transfer of risk onto one volunteer.

"We just ask people to reply in the thread"

This works up to roughly thirty and then quietly stops. The replies keep arriving, so nothing looks broken, but nobody is counting them accurately any more.

There is also the update problem. A reply saying yes three weeks ago is still sitting there saying yes, and the person who has since booked a holiday has no way to take it back that anyone will see.

The vocabulary that makes this arguable

Most arguments about big community events go badly because everyone is using one word for six things. A few distinctions make the conversation short.

Member

Someone who joined the group at some point. A fact about the past with no bearing on Saturday.

Reach

How many people had the chance to see a given message. Always smaller than membership and never precisely knowable.

Interest

A reaction, a vote, a comment. Cheap by design, which is what makes it a bad basis for a booking.

Commitment

A named person saying they will be at a specific event. It has an owner and it can be withdrawn, which is what makes it useful.

Capacity

The hard limit of the room. The only number in this list set by physics rather than enthusiasm.

Attendance

Who actually arrived. Knowable only afterwards, and only if somebody was counting.

Say to a co-organiser that you have reach but no commitments and the problem lands immediately. Say the group has three hundred members and everyone nods at a number that means nothing.

Where Ontaym fits

This is the one section with a product in it, and it exists because the argument above points somewhere specific.

Ontaym holds the event as a record rather than a conversation. One address for the time, the place, the cap and the list of people who said they are coming.

Your community stays exactly where it is. The channel keeps announcing, the group keeps talking, and both point at the same link instead of retelling it, which is the same move that helps when a group is trying to keep event information organised inside Telegram.

Guests answer without joining anything or handing over a phone number to three hundred strangers. When something moves, it moves in one place and everyone who looks sees the current version.

It will not tell you the weather. It will give you a defensible number to say out loud to a bar manager, which is most of what was missing.

What this actually comes down to

Telegram is not the problem here, and that is the interesting part. It gives you a room bigger than any venue, a broadcast that beats a mute, polls, bots, scheduling and pins.

What it does not give you is a list. Every one of those features moves information outward, and an event at this size fails on the return journey.

So the test is simple. If somebody outside your community needs a number from you, ask whether anything in your setup can produce one without a person reading and counting.

If the answer is no, more features will not help. What is missing is a place where a commitment can live with a name on it, and everything else you are doing is an impression of that place, performed by hand.

Frequently asked questions