How to See Who Viewed Your Telegram Post

You post something, the little eye icon underneath fills up with a number, and the number tells you almost nothing. Two thousand what? Two thousand people? Two thousand devices? Two thousand accounts that scrolled past on the way to somewhere else? And the question underneath that one, the one everybody actually types into a search box, is simpler and blunter: can I find out who they were.

The honest answer is that there are four answers, and which one you get depends entirely on where you posted the thing. A channel post gives you a bare counter and no names at all. A group message can give you a list of exactly who read it, with the minute each of them did, but only under two limits that are published as numbers. A private message gives you the precise second the other person read it, unless one of you has switched something off. A story gives you a full list of viewers, which then closes and cannot be reopened.

So the question is not really answerable until you say where the post lives. This article goes through all four surfaces in order, the exact limits on each, the refusals you get when you cross them, the reciprocity rule that quietly costs you the read date on your own private chats, what channel statistics contain and who is allowed to see them, and how to read any of these numbers without lying to yourself. Every limit, refusal and field named below was pulled from Telegram's own documentation and live configuration on 9 August 2026 rather than remembered.

The Question Has Four Different Answers

Where you posted decides what you get

It is worth fixing this in your head before anything else, because it is the reason two people can ask the same question and both be right with opposite answers. There is no single view mechanism. There are four separate ones, built at different times for different reasons, and they expose different things. Somebody who mostly uses groups will tell you that of course you can see who read a message. Somebody who runs a channel will tell you that of course you cannot. Neither is confused.

The four surfaces, plainly

A channel post has a view counter and a forward counter, and neither carries any identity. A group message has a read participants call that returns user identifiers with times. A private message has a read date call that returns one timestamp. A story has a viewers list that returns people, times and reactions. Four surfaces, four different amounts of truth, and no way to borrow one surface's answer for another.

Why this trips people up constantly

Because the interface shows the same small eye icon in more than one place, and an icon that looks the same implies a mechanism that works the same. It does not. The eye under a channel post and the double tick in a private chat are not two views of one system, they are two systems that happen to sit near each other. Once you stop expecting them to agree, the rest of this stops being surprising.

The second reason is that the answer changed over time. Read dates in private chats and viewer lists on stories are both newer than the channel view counter, so a lot of advice written a few years ago is describing a smaller feature set and is confidently wrong today. Checking the current documentation rather than the current folklore is the whole method here, and it is why every limit in this article carries a date.

Channel Posts Give You a Number and Nothing Else

What the call actually returns

The endpoint behind a channel post's view count is documented as getting and increasing the view counter of a message sent or forwarded from a channel. What comes back is a structure holding a view count, a forward count, and reply information. There is no list, no identifier, no partial sample of who was there. The counter is a scalar and that is the whole design.

Views and forwards are optional fields

A detail worth knowing if you have ever seen a post with no number under it at all. In the returned structure, the view count and the forward count are both conditional fields rather than guaranteed ones, along with the reply information. A message can legitimately come back carrying none of them. That is not an outage and not your client misbehaving, it is a field that was not set.

The refusals tell you the shape of the wall

Ask about a channel you have not joined and you get told you have not joined this channel or supergroup. Ask with a broken identifier and you are told the channel is invalid, or the chat identifier is invalid, or the peer identifier is invalid, or the message identifier is invalid. What you never get, at any point, in any error path, is a partial answer with names in it. The absence is structural rather than a permission you might one day be granted.

There is one adjacent surface that does leak a few names, and it is easy to miss. The reply information attached to a post carries a short list of recent repliers for channel post comments, along with the identifier of the latest message in the thread and the latest one marked as read. So the comment section under a broadcast is slightly more transparent than the broadcast itself, which is a reasonable thing to know before you write something in it.

The Counter Can Be Pushed Up on Purpose

The increment flag is documented

This is the part that changes how you read every view count you have ever seen, including your own. The same call that reads the counter takes a flag whose documented meaning is whether to mark the message as viewed and increment the view counter. Reading and increasing are the same operation, and whether the increase happens is a parameter the caller sets.

What that means for numbers you are buying

If somebody offers you views on a post, understand what is being sold. Not attention, not people, not even accounts that opened the app. What is being sold is repeated calls with that flag set. The number goes up because the number is designed to go up when asked. Anyone comparing channels by view count alone is comparing how often that call was made, which is not the same as how often the post was read. Our own notes on how a botted channel looks from the outside come at the same problem from the other end.

How to spot it without any special access

You cannot audit somebody else's counter directly, but you can look at what a counter cannot fake cheaply. Forwards, comments, reactions and joins all require a real account doing a second thing after the view. A channel with an enormous view count and almost no forwards is telling you something. So is one where every post lands within a few percent of the same number, because genuine reach is lumpy and inflated reach is smooth.

The other cheap check is the oldest posts. Inflation is usually bought for recent material, so a channel showing the same heavy numbers on a post from eighteen months ago, sitting quietly at the bottom of the history with nothing under it, is worth a second look. None of this is proof and none of it needs to be. You are deciding whether to spend money, not writing a report.

Groups Are Where the Names Live

The call that answers the real question

For groups and supergroups there is a call whose documented purpose is to get which users read a specific message. This is the one people mean when they ask the question in the title. It is not a workaround, not a bot trick and not something scraped from the side. It is a first class part of the protocol with its own error table.

What comes back is a person and a moment

Each entry in the response contains a user identifier and a date, described as when the user read the message. Not an approximate window, not an ordering, an actual time per person. If you have ever wondered whether the person who did not answer had at least seen it, this is the surface that answers, and it answers with a timestamp.

It is worth pairing that with the mechanism that creates those entries, which is the ordinary call that marks message history as read. Receipts are a side effect of somebody's client catching up rather than a separate report anybody files. That is why a person who has the chat open but has not scrolled down to your message has not read it in this sense, and why the answer sometimes lags reality by a few seconds.

Why this exists in groups and not channels

Because the two are different social objects wearing similar clothes. A group is a room with a known set of people in it, where knowing who has caught up is ordinary and useful. A channel is a broadcast to an audience that never agreed to be individually enumerated. Telegram drew the line at that difference rather than at any technical boundary, which is why the same feature stops existing when a room turns into an audience. If you are pushing against that boundary because your group has grown, splitting it into topics is the structural answer rather than the reporting one.

The First Wall: One Hundred Members

The number is published, not inferred

The documentation says the call is only available for groups and supergroups with fewer members than a configuration value, and that value is published in the live client configuration. On the day this was written it read one hundred. So the rule in plain language is that read receipts work in groups of under a hundred people and stop working above that.

The refusal is explicit about it

Cross the line and you do not get an empty list, which would be ambiguous and awful. You get a refusal saying the method is not available for groups with more than that threshold of members. The error names the reason. Any tool that reports a group as having no readers when it actually has too many members is misreading a refusal as a result.

What it feels like from the inside

It feels like a feature breaking, because the group did not change in character on the day it crossed the hundredth member. You still know everybody. The receipts still worked last week. But the threshold is a member count and nothing else, so the day the number ticks over, the panel goes quiet. Knowing the reason turns a bug report into a shrug, which is most of what documentation is for.

The same hundred turns up in a second place, which suggests a deliberate boundary rather than an arbitrary one. The configuration also carries a minimum group size for hiding the member list, and on the same day it read one hundred as well. Below that number a group is treated as a room where everyone is visible to everyone. Above it, both the member list and the receipts become things that can be closed.

The Second Wall: Seven Days

Receipts are stored for a fixed period

The same sentence that gives the size limit gives a time limit: read receipts are stored for a configured number of seconds after the message was sent. That value, again read from the live configuration rather than remembered, was six hundred and four thousand eight hundred seconds. That is exactly seven days.

The refusal names the reason

Ask after the window and the answer is that the storage period has passed and the receipts are gone. Not that nobody read it. Not that you lack permission. The information existed, was kept for a week, and was discarded on schedule. This distinction matters if you are building anything that reports on old messages, because a naive implementation will quietly turn expired into unread.

Why a week rather than never

Because a receipt that never expires stops being a convenience and becomes a permanent record of when each person in a room looked at their phone. Seven days is long enough to answer did they see it, which is a real question, and short enough that nobody accumulates a year long attendance log of their colleagues. It is a deliberate trade and worth understanding as one.

Private Chats Give You a Timestamp

One message, one person, one moment

For a message you sent to one other person there is a call documented as getting the exact read date of one of our messages, sent to a private chat with another user. Note the wording. Not an approximation and not a status flag, the exact read date. This is the most precise of the four surfaces and also the most fenced.

Not read yet is a separate answer

If the message has not been read, you do not get a null or a blank. You get a refusal saying the specified message was not read yet. That is a genuinely different state from any of the others and it is worth keeping separate in your head, because it is the only one of these answers that might change five minutes later.

Too old is another separate answer

There is a second refusal saying the message is too old and the requested information is not available. So the private chat surface has its own expiry, in the same spirit as the group one. Between the two you have three distinct outcomes that a careless reading collapses into one: not read, read at this time, and no longer knowable.

The practical consequence is that the read date is a live question rather than a historical one. If it matters whether somebody saw a message, check while the answer still exists, the same way you would with a story viewer list. Building a habit around that is less work than building a system to store the answers, and it fails in a much more obvious way when you forget.

The Reciprocity Rule Nobody Expects

You cannot hide yours and read theirs

Here is the part that surprises almost everyone. Among the refusals on that call is one that has nothing to do with the other person. It says you cannot fetch the read date of this message because you have disallowed other users from doing the same to you. Switch off your own read visibility and you lose the ability to see anybody else's. The setting is not one directional.

Which setting actually controls it

It sits in the global privacy settings as a flag whose documented effect is that your last seen privacy key will also apply to the ability to read your read dates. In practice that means the control you already set for who can see your last online time silently governs read receipts too. One switch, two consequences, and the second one is not obvious from the label.

Why this is the right design even though it annoys people

Because the alternative is a one way mirror, and one way mirrors always get used by whoever cares least about the other party. Tying the two together means the person who wants to know when you read things has to accept you knowing when they read things. It is the same logic that makes read receipts tolerable in the first place, applied to the privacy setting rather than the feature.

Stories Give You an Actual List

People, not a counter

The story surface is the one that answers the title question most completely. The call is documented as obtaining the list of users that have viewed a specific story we posted. A list of users. If you have been told flatly that Telegram never shows you who saw your content, this is the counterexample, and it is not obscure or new.

Each entry carries more than a name

An individual view record contains the user who viewed it, when they viewed it, and optionally the reaction they left. It also carries two flags about your relationship to them: whether you have blocked that user completely, and whether you have blocked them specifically from seeing more of your stories. The record is about the interaction rather than just the impression.

The aggregate view has its own shape

Alongside the full list there is a summary object holding a view count, a forward count, the reactions themselves, a reaction count, and a short list of recent viewers. That summary is what feeds the small preview of faces you see without opening the full list. Two different objects, one detailed and one glanceable, and it helps to know which one you are looking at.

There is also a batch call that pulls view counts, forward counts, reactions and recent viewers for several stories at once. If you post stories regularly that is the call behind any sensible overview screen, and it is why a good client can show you a week of stories with numbers on them without making one request per story. Ask it about somebody who has never posted a story and it tells you exactly that.

The Story Viewer List Closes After a Day

Twenty four hours, read from configuration

The viewer list is not permanent. The live configuration carries a story viewers expiry period, and on the day of writing it held eighty six thousand four hundred seconds. That is twenty four hours. After that the detailed list is no longer available to you, even though the story itself and its counters may still be around.

There is a flag that tells you

You do not have to guess whether the window has closed. The summary object carries a flag whose documented meaning is that the viewers list is currently viewable. Check the flag rather than calling and interpreting the silence. This is a small thing that separates a tool which reports honestly from one that reports absence as zero.

Plan around it instead of discovering it

If who saw a story matters to you, look on the day. Not next week when you are doing your reporting, not at the end of the month. The practical version of this rule for anyone posting regularly is to build the check into the posting habit itself, which is the same argument as posting on a schedule you actually keep rather than when you remember.

Filtering a Long Viewer List

Contacts only

The viewers call takes a flag to fetch only the views and reactions made by your contacts. On a story that travelled further than expected this turns an unusable wall of strangers into the twenty people whose opinion you were actually curious about. It is the most useful of the filters and the least known.

Reactions and forwards first

Two more flags reorder rather than reduce. One returns the people who reacted ahead of the people who merely watched. The other puts forwards and reposts at the front, then reactions, then plain views. Since the list is paginated, ordering is not cosmetic. It decides what you see on the first page, which for most people is the only page they will read.

Searching for one person

There is also a search parameter for finding specific peers within the viewer list. If the question is not who watched but whether one particular person watched, that is a search rather than a scroll. Worth remembering before you page through four hundred entries looking for a name you already know.

All of this sits on ordinary pagination, with an offset carried forward from the previous response and a limit on how many entries come back at a time. That matters, because it means the filters and the ordering are not conveniences layered over a full list you already hold. They shape which entries you ever receive, so choosing them badly on a popular story leaves the answer you wanted on page nine while you stop at page two.

Channel Statistics Are Aggregate and Admin Only

Admin rights are enforced at the endpoint

Channel statistics are a separate system from view counters, and they are gated. The message statistics call and the channel statistics call both list a refusal saying you must be an admin in this chat to do this. That check happens at the protocol level, so no client, bot or third party dashboard can go around it. Which rights a given admin actually holds is its own subject, covered in the breakdown of every admin permission.

Channels and supergroups take different calls

Point the broadcast statistics call at a supergroup and you are told that the method can only be called on a channel and that you should use the supergroup version instead. Two objects, two endpoints, and an error that names the correct one. Tools that treat every chat as one type produce confusing failures here for no good reason.

What the report contains

The channel report is built from paired current and previous values rather than bare numbers, so every figure arrives with its own comparison. It carries followers, views per post, shares per post, reactions per post, and the same three per story. Next to those sit growth, followers, mute, top hours and interactions graphs. Per post interaction counters give views, forwards and reactions for individual messages and stories. If you want that shape without being an admin of somebody else's channel, our own channel analytics tool reads the public side of it.

One structural detail explains a lot of odd behaviour on statistics screens. Graphs do not always arrive as data. They can arrive as a token to be fetched separately, or as an error object carrying a message. So a panel that shows numbers immediately and charts a moment later is not being slow, it is doing what the protocol describes, and a chart that never loads is a returned error rather than a broken page.

The Number Most Owners Never Read

The share of subscribers with notifications on

Buried in the same report is a percentage: enabled notifications. Not how many people subscribed, but what proportion of them will actually be told when you post. It arrives as a part and a total rather than a rounded figure, so you can see both halves.

Why it explains a flat view count

If that percentage is low, your view count is being set by how many people happen to open the app rather than by how good the post was. Every improvement to the writing runs into the same ceiling, and it looks like the content is the problem when the problem is that most of your audience muted you. Nothing else in the report explains a stubborn plateau as cleanly.

What to do about it is not more posting

Posting more often into a muted audience makes the ratio worse, not better, because people mute channels that post too much and they rarely unmute. The lever is fewer and better, plus a reason to turn notifications back on. That is a content problem, and the engagement guide goes at it properly rather than in three sentences.

Forwards Name Channels, Not People

The public forwards call

There is a call that obtains a list of messages showing which other public channels a channel message was forwarded to. Read that carefully, because it is a rare thing. You do get identities here. They are simply not the identities of individuals, they are the public channels that carried your post onward.

What you learn from a list of channels

More than you would think. It tells you which rooms are relaying you, which is a map of where your audience overlaps with somebody else's, and it is the cheapest research available to a channel owner. A post that spread through five channels you have never heard of has just told you five places worth studying, and possibly worth paying to appear in deliberately.

It is also a much better test of a post than the view counter is. Views tell you the post reached people who already follow you. Public forwards tell you it left the building. A post with modest views that got picked up by three unrelated channels did more for you than a post with double the views that stayed exactly where you put it, and only one of those two facts shows on the surface.

Stories have their own version

The same idea exists for stories, as a call that obtains forwards of a story as a message to public chats and reposts by public channels. Note that reposts count as forwards there. The two are one number in this report even though they feel like different acts, which is worth knowing before you try to reconcile it against something else.

Reading Your Own Numbers Without Fooling Yourself

A view is a delivery, not attention

Everything above should make the point on its own, but it is worth saying plainly. The counter records that a post was fetched and marked as seen. It does not record that a sentence was read, a decision was made, or a human was present. Treat it as a delivery receipt and it is genuinely useful. Treat it as an audience measurement and it will mislead you every single month.

Compare posts, not days

Because the report gives you per post figures and per post comparisons, the honest unit is the post. Daily totals move with how often you posted, which you already know, so they mostly measure your own behaviour. Views per post against the previous period is the figure that answers whether anything actually changed.

Forwards per view is the ratio worth watching

Views are the cheapest number to inflate and forwards are among the most expensive, since a forward needs a real account to make a decision after reading. The ratio between them is therefore much harder to fake than either alone. If you track one derived number, track that one, and read a falling ratio as a content signal well before the view count admits anything.

When the numbers and the room disagree, believe the room

Comments, questions, replies and joins are noisier than counters and far more honest. A channel where the counter climbs while the comment section goes silent is not growing, whatever the eye icon says. If you are running that channel as a business rather than a hobby, the numbers that matter sit further down the funnel anyway, in replies and conversations, which is what running Telegram as a customer record is really about. Teams handling those replies at volume usually end up in a proper account tool rather than a phone, and the outbound side of the same conversation lives in the direct message product.

Frequently Asked Questions

Can I see who viewed my Telegram channel post

No. Channel posts expose a view counter and a forward counter and no identities at any point. The call that returns them carries a view count, a forward count and reply information, and no list of users exists in the response or in any error path.

Can I see who read my message in a group

Yes, in groups and supergroups below a size threshold. The response gives a user identifier and the time each person read it. The threshold read one hundred members in the live configuration on 9 August 2026, and above it the call is refused rather than returning an empty list.

Why did read receipts stop working in my group

Almost certainly because the group grew past the member threshold. The refusal explicitly says the method is not available for groups with more than that number of members. Nothing was switched off and nothing is broken, the group simply crossed a published line.

How long do group read receipts last

Seven days. The stored period is a configuration value that read six hundred and four thousand eight hundred seconds, and after it passes the call refuses with a message saying that period has elapsed. That is different from nobody having read the message, and tools should not report the two the same way.

Can I see exactly when someone read my private message

Yes, there is a call for the exact read date of a message you sent in a private chat. It has separate refusals for a message that was not read yet, a message that is too old, and privacy settings on either side that block the request.

Why can I not see read dates even though the other person can

Because you have hidden your own. One of the refusals says you cannot fetch the read date because you have disallowed other users from doing so to you. The relevant privacy flag ties your last seen setting to read dates, so hiding one hides the other and costs you the ability to see either.

Can I see who viewed my Telegram story

Yes, and this is the fullest answer of the four. The call returns a list of users who viewed the story, each entry carrying the user, the time they viewed it and any reaction they left, plus flags showing whether you have blocked them entirely or only from your stories.

Why has my story viewer list disappeared

It expired. The viewers expiry period in the live configuration was eighty six thousand four hundred seconds, which is twenty four hours. The summary object carries a flag stating whether the list is still viewable, so a well built client can tell you the window closed rather than showing an empty list.

Are Telegram view counts reliable

They are reliable as a record of how many times the view call was made, which is not the same thing as how many people read the post. The same call takes a documented flag controlling whether it increments the counter, so the number is inflatable by design and should be read next to forwards and replies rather than alone.

Do I need to be an admin to see channel statistics

Yes. Both the channel statistics call and the individual message statistics call refuse with a message saying you must be an admin in this chat. The check sits in the protocol, so no client or third party dashboard can work around it for a channel you do not help run.