Methodology

How we measure, and what we refuse to claim

Every number on this site was read off a public Telegram surface by our own crawler, on a date we record. Nothing here is licensed from an analytics vendor, scraped from another directory, or supplied by a channel owner. This page is the part you should read before trusting any of it.

What we read, and how often

There are four public surfaces, and each is a separate lineage of readings that never merges with another’s:

Readings from different surfaces never confirm each other.A count read from the profile page and a count read from the preview header are recorded as separate lineages, because one is exact and the other is rounded to three significant figures. Letting a rounded reading “confirm” an exact one would turn a real change into a false flat line, and a real flat line into a change. Each stored reading carries how many times it has been re-observed, and by which lineage.

Subtraction inherits that rule. Working out how much an entry gained or lost is a stronger operation than confirming a figure, so the movement boards compute a change only between two readings of the same page — the t.me/name profile, where the counter is printed in full. The preview surface stores the figure it was handed by an earlier profile read rather than its own rounded header, so its timestamp is when the entry was catalogued and not when the number was measured; on this database that gap reaches 29 hours. Subtracting across it would attribute a change to hours in which nothing was read. Far fewer entries can be given a movement than hold two readings overall, and that is the reason.

Cadence. Every live entry is re-read on a schedule set by its size: every 24 hours above 10,000 subscribers, every 72 hours above 1,000, every 7 days below that. Post view counts are re-read far more often than that — the reader that tracks them runs every five minutes across the corpus — because a view count only ever goes up and the interesting part is the shape of the climb.

Snapshots are written on change.A re-reading that agrees with the stored one does not create a new row; it stamps the existing row as confirmed again. So a gap in a growth chart means “no change observed”, never “not measured” and never “interpolated”. Straight lines between measured points on our charts are drawn to join two readings, not to claim we know the path between them.

That is why “Measurements held” and “Confirmed unchanged” are two different rows on an entry’s page, not one. The first counts distinct readings — rows in the table. The second counts how many times the LATEST one has been independently re-observed and found identical, which a re-read that changes nothing never adds a row for. An entry can therefore hold one measurement and still say “Confirmed unchanged 4 times, most recently <date>” — a real, repeated finding no directory that only stores the current figure can make, and a different claim from a single reading nobody has looked at again. The row is omitted entirely when the count is zero: “confirmed zero times” is not a finding, it is simply what every entry starts at.

We never republish somebody else’s number. Not a figure from another Telegram directory, not a figure from an analytics product, not a figure a channel published about itself. If we could not measure it, it is not here — which is why entries carrying a single measurement say exactly that instead of showing a trend.

Channel creation dates: measured where we can, estimated where we cannot

Until 2026-08-08 a channel’s age on this site was inferred from the earliest post we happened to hold — bounded by how deep our own crawl reached, not by when the channel was actually created. Checked against 45,807 real creation dates, that method was out by a median of 2,402 days (6.6 years) and landed within 90 days of the truth 1.6% of the time. It has been replaced everywhere on this site by a dedicated measurement, worded below exactly as it is worded in the worker that produces it (agecal.py), because the distinction it draws is the entire point of publishing this field at all.

Four sources are genuinely MEASURED, and one is an ESTIMATE — and this site never lets the two look alike. A measured date is printed as a fact, the same as a subscriber count. An estimated one is printed only as a range, labelled as a range, because it is one.

Where several measured sources exist for one channel, the EARLIEST wins — not the highest-priority source, the earliest date — because the question is when the channel was actually founded, and an earlier, independently measured date is closer to that answer than a later one from a source ranked first for tie-breaking purposes only.

The estimate is honest about how wide it is, and the band is calibrated, not decorative. created_est_lo / created_est_hiare the 10th and 90th percentile of the REAL creation dates of measured channels whose ids sit in the same neighbourhood — not a fixed margin applied everywhere. Held out against 186,000 test channels the band actually contains the truth 80–82% of the time in every id range checked, which is what “10th to 90th percentile” is supposed to mean and is confirmed to mean here:

The 1.15–1.50 billion range is not a fitting failure and more measured anchors will not narrow it: Telegram issued those ids over roughly four years, so the real creation dates in that range span 2017–2021 with an interquartile range of about 650 days at any single id — both third-party datasets and our own first-message dates show the same spread independently. A date in that band is genuinely uncertain by years, and the band says so rather than hiding it behind a confident-looking single figure. Corpus-wide, the estimate’s median error is 137 days, against 1,804 days for the earliest-held-post method it replaced.

What this site will not do with either kind of figure. A measured date is never rounded into a range, and an estimated range is never collapsed into a bare date — even though created_est holds a single date value for both, only created_est_measured = true rows print it. first_seen, printed elsewhere on a channel page as “First recorded”, is a different fact entirely — the date OUR crawler first observed the channel — and this site has never mapped one onto the other, in prose or in structured data.

The groups register

A second register, alongside the channel one above, covering public Telegram groups and supergroups. It was not built as a new project: the re-measurement worker has read groups (alongside channels and bots) on the same tiered cadence since it was first written, and nobody had measured what had accumulated until it was checked. Everything below describes what that worker already does, published rather than newly built.

Member counts are read exactly the way subscriber counts are— off the group’s own t.me/<name>public profile page, printed in full and not short-formed, the same surface and the same exactness guarantee a channel’s count carries. Where Telegram shows how many members are online at that moment, that reading is stored too and carried on the group’s page exactly as a channel’s is.

Groups are not resolved to a numeric Telegram id.A channel’s free id trick works only on the t.me/s/<name> post-preview page, and a group redirects away from that surface rather than rendering it. So a group is tracked by its username throughout, on its own tables, rather than being promoted into the channel register the way a discovered handle normally would be — this is a design choice that keeps the group register cheap to run, not a gap being worked around. It is also why a group page carries no post archive, no engagement figures, no reactions and no citation graph: none of that is built from a numeric id this register does not hold for a group, and there is no post-reading crawl aimed at groups to build it from.

The same liveness rule. A group recorded as no longer answering has met the identical bar described under why a dead handle needs two independent sightings — two independent, IP-verified sightings an hour apart, re-checked a month later. The count shown beside it is the last measurement taken while the handle still resolved, not a current figure.

The same measured-depth index gate, on two of its three paths. A group page is offered for indexing once it holds at least MIN_MEASUREMENTS readings spanning at least MIN_SPAN_DAYS days, or once its latest measured count reaches MIN_SUBSCRIBERS — the identical thresholds the channel register’s own gateuses, imported rather than restated so raising one raises both. There is no equivalent of that gate’s third path (an active observation): no detector here writes findings against a group, because clones.py, erratio.py and velocity.py all key off a numeric channel id groups do not have.

Two things this register will not do with a group, ever. It will never publish who is in a group — member counts are aggregate and published; member identities are membership, and membership is not collected at all, at any point in the pipeline, for any group. And it will never publish a Telegram user account as an entry: 1.2 million of them are held for the same reason the groups above were — a discovered handle has to be fetched before anything knows what it resolves to — but a user account is an identifiable person, not a community, and retaining what discovery already measured is a different decision from building a searchable index of people. There is no page, no listing and no download for a user account anywhere on this site.

Declared links: a declaration, never a verified association

A channel or group’s public description sometimes carries a URL — its website, its shop, its account on another platform. Where it does, we show it, on both the channel and the group page. What is measured is that the description contained that text. Nothing about whether the linked site is really run by, or connected to, the entry that named it is checked, because a description is not evidence of that — it is text the entry itself controls, and anyone can type any URL into a bio. This section is never worded as ownership.

Every declared link carries rel="nofollow noopener external" — the same attribute this site has always put on its own t.melinks, extended here because it matters more: these are URLs a stranger chose, not Telegram’s own domain, and some of what people put in a bio is malicious. No search engine credit and no referrer information passes from this register to any of them.

A domain a threat-intelligence feed has flagged is shown as text, not as a link.This register already runs domains through a small set of public blocklists for other purposes (see the citation-graph and observation sections above for the general doctrine on third-party assertions); a declared link is checked against the same data before it is ever made clickable. The check is deliberately narrow: a blocklist entry can name a specific subdomain rather than a whole site, and this register never extends a subdomain’s listing to every other address that happens to share its root domain — a declared link is withheld only when its own exact address is the one a blocklist actually named, not merely because it shares a domain with something that was. Where a link is withheld, the domain is still shown as plain text and the page states why, because the declaration itself is still a measured fact even when the address is not one we will send a reader’s click to.

Why view counts above 1,000 are approximate

Telegram does not print exact view counts on its public post preview. It prints them in short form — 8.12K, 3.7M, 951 — which is three significant figures for anything at or above 1,000, and the exact number below it. There is no second surface with the full figure on it. So:

• A view count below 1,000 is exact. A view count of 8,120 is somewhere in [8,115, 8,125); a view count of 3,700,000 is somewhere in a band 10,000 wide.
• The rounding is recorded at parse time, from the suffix itself — a column travels with every reading saying whether it arrived short-form. It is not re-derived later by guessing from the magnitude, because a genuinely round number and a rounded one are indistinguishable after the fact.
• Anything computed from those readings is shown to the same precision, never finer. An average of rounded readings printed as 3,701,250 asserts four digits nobody measured; we print 3,700,000.
• Where a comparison depends on the precision — the engagement-rate cohorts, for instance — the rounding is propagated into an explicit uncertainty, and a channel whose uncertainty exceeds 2% of the figure is left out of the comparison rather than included with a footnote.

Subscriber counts are exact where we have measured them. The profile page prints the full number and that is the one we store. The rounded counter on the post-preview header is never written into the time series — a rounded figure inside a series of exact ones would make every subsequent change calculation wrong.

Reaction counts are rounded too, and in a way that hides itself. Telegram publishes them per emoji, and short-forms each one exactly as it does views — we have checked every per-emoji reading we hold at or above 1,000, and all of them sit precisely on the three-significant-figure step. What we store is their sum. A sum of rounded parts is usually not itself a round number, so a reaction total of 8,847 looks exact while carrying error from every contributing emoji above 1,000. A total below 1,000 is exact. Read a larger one as three significant figures per emoji, not as the figure it prints.

What we cannot compute at all.The industry ER metric is (forwards + reactions + comments) ÷ views. Telegram’s public preview carries views and reactions but neither forward nor comment counts, so we publish the reactions term alone and label it a floor. We do not estimate the rest. A channel page shows the reaction rate as what it is — a lower bound on ER — rather than presenting a third of a numerator as the whole metric.

What a post carries, and what we do with it

A channel page shows four things read off the posts themselves that no other Telegram directory publishes. Each is measured, each has a limit, and the limit is on the page beside the figure:

All four are measured over a bounded sample, and the page states it. The figures are computed from the most recent 1,000 posts we hold for an entry, and every section prints how many that was and the dates the sample spans. The register holds nearly half a million posts for its largest entries, and an aggregate over the whole history of one costs five seconds of database time; a bounded, dated sample is the honest version of a figure we can actually recompute on every refresh. For the typical entry — the median one holds nineteen posts — the sample is everything we have.

Most entries have none of this.Stars are rare, marked advertising is rarer, and the majority of channels have never posted a poll. A section that has nothing to show renders nothing rather than a panel of zeroes: “this channel takes no Stars” and “we measured no Stars” are different claims, and only the second is ours to make.

Citation-graph rank, and why it is never a score

A weighted position computed over the union of two edge sets, both read only where we hold BOTH sides of the relationship: the forward graph (who has republished a channel’s posts into their own feed) and the mention graph (who has typed a channel’s handle into a post body, without necessarily republishing anything). A channel page’s own Citations section lists these edges by name. Forwards weigh more than mentions in the computation — republishing a post is a stronger act than typing a handle — and the position is recomputed periodically over the whole graph by a worker outside this app, not on a fixed schedule tied to any single channel’s own re-reads.

Published only as an ordinal position, never as a score. “1,204th of 319,606” is a fact about where an entry sits inside a measured graph. A number scaled to a fixed range and printed beside one channel’s name would read as this register’s verdict on that channel — the same overclaim severity zero exists to rule out for an observation, above — so the underlying figure the worker computes is never shown on any page, and this site does not use the word this field is named after in its own copy for that reason. The top 100 is the closest thing to a leaderboard this measure gets, and even there the only number printed for the rank itself is the row’s position.

The two edge counts stay separate everywhere this appears. Weighting forwards and mentions together inside one computed position is not the same operation as summing their counts into one number, which this site never does — see Mentions, above. Every page that shows a position also shows the forwarded-by and named-by counts it was built from, because a named-by count on its own is weak evidence: a mention costs nothing to place, and a reader should be able to see how much of a position rests on one.

Coverage is partial, deliberately and by construction.Only entries the crawler has read a forward or mention edge for — on both sides of it — hold a position at all. The rest are not ranked at the bottom; they are absent from the graph the same way an unmeasured channel is absent from a size band, and the coverage figures are published in full rather than left for a reader to infer from a gap.

A channel page’s “Named by N registered channels” line is a related but separate figure from this rank. It counts every registered channel that has named THIS one, merged from two independently captured mention readings — the resolved graph this rank is built from, and a larger, later index (mention_handle_edge, 2,354,960 rows, landed 2026-08-08) that keeps a mentioned handle whether or not it happens to resolve to a register entry, read back here by the reverse lookup on the handle actually named. A namer both readings caught counts once, at whichever reading recorded the larger post count — never summed, for the same reason nothing else on this page sums two measurements of one fact.

“Similar channels”: Telegram’s answer, not ours

Some channel pages carry a section showing channels Telegram itself considers similar, in both directions — what Telegram recommends alongside this channel, and which other channels’ recommendation lists this one turns up in. Both come from a single MTProto call, channels.getChannelRecommendations, polled by a worker (recommend.py) every 20 minutes and simply recorded — the relationship, and the order Telegram returns it in, are Telegram’s computation, on criteria Telegram has not published. This register does not compute, choose, or re-rank this list in any way, and both sections say so in their own words for the same reason the channel header attributes is_scam/is_faketo Telegram by name rather than stating them as this register’s own findings: an unattributed “similar channels” list would read as this register’s editorial judgement about which channels resemble each other, and no such judgement has been made.

Coverage is 425 channels out of roughly 1.2 million on the register, measured 2026-08-08. the register works through the corpus gradually, and that figure grows over time; it does not grow evenly, since a channel can only be asked about once it has been discovered at all. The overwhelming majority of channel pages therefore show nothing in this section today. Absence means we have not asked Telegram for this channel’s list yet— it is not a reading of “Telegram has no similar channels for this one”, and must never be read as one. The same distinction the rest of this register draws everywhere else between an unmeasured channel and a measured zero applies here without exception.

The outbound list is never re-sorted.When this channel was the one asked about, the channels Telegram named back are shown in Telegram’s own rankorder — position 1 is the first result Telegram itself would show — never reordered by subscriber count or by anything else this register measures. Doing so would substitute this register’s own judgement for the one thing the section exists to attribute away from itself.

The inbound list is a different, and arguably more interesting, signal. It does not require this channel to have ever been queried directly: it is built from the reverse of the same table, and shows every other channel whose own Telegram-generated list happened to include this one. A channel that has never been a seed itself can still appear here, because being named by someone else’s query does not depend on having been queried itself.

Handles and subscriber counts on either list are shown live, from this register’s own current reading, wherever the named channel is one we hold a page for. Where it is not — or where we hold no live reading yet — the figures Telegram returned at read time are shown instead, dated to that reading rather than presented as current. A page is never linked unless it is one this register actually publishes, the same rule every other cross-reference on this site follows.

Why a dead handle needs two independent sightings

Telegram answers a throttled request with HTTP 200 and a “username not found” page that is byte-identical to a genuine vacancy. There is no status code, no header and no marker distinguishing “this handle does not exist” from “you are asking too fast”. That has corrupted this dataset twice.

The consequence is an asymmetry we build everything around: a channel that answers is alive, on sight — a page that renders a real title and a real counter cannot be faked by a rate limiter. A channel that does not answer has proved nothing. Absence is never taken at face value. Before a handle is recorded as dead, all four of these must hold:

1. The exit IP must be proved honest after the fact.Immediately after reading a handle down a given IP, we read a different, known-good handle down the same IP. If that check does not come back healthy, everything read through that IP in that window is discarded and the work is redone. An absence observed through an unverified IP is not recorded as an absence at all — it is recorded as “nothing was learned”, and the database is left exactly as it was found.
2. Two sightings, not one. A single verified vacancy schedules another look; it does not conclude anything.
3. The two must be independent — a different exit IP, and at least an hour apart. A throttling episode that begins and ends between one read and its verification can fake a single sighting. Faking two, on two different addresses, an hour apart, it cannot.
4. And the channel must have no resolving handle left. A channel that dropped one of several usernames is very much alive; only the handle is retired.

Even then it is parked rather than buried: a handle recorded as dead is re-probed a month later and quietly resurrects itself if anything answers. A wrong verdict therefore expires on its own instead of being permanent. Entries in this state are labelled “no longer answering” and the count shown beside them is explicitly the last measurement taken while the handle still resolved — not a current figure.

The same asymmetry governs what gets a page at all. The register holds millions of queued handles; none of them is coverage, and none becomes a page. A handle we have measured once — a real count and a real title, read on a date — is shown as a measurement in search results and is deliberately not linked, because one reading of two fields is not an entry. A page exists only once a channel has been scanned, resolved and measured.

Why a page can be crawlable and not indexed

Crawling and indexing are two different switches, and this register only flips them together when an entry has earned it. Every page on this site can be fetched — robots.txt has allowed the whole site since launch, precisely so a not-yet-indexable page still passes its links onward. Whether a fetched page may be kept in a search indexis decided separately, per entry, by lib/depth.ts’s one definition of the test below — read by this site’s own sitemap and by every channel page’s own metadata, so the two can never disagree about which URLs are offered for indexing.

The aggregate pages — this one, the browse facets, the movers boards, the ERR baselines, the home page — are deep, whole-register pages with measurements nobody else publishes, and have been indexable since launch. A channel page is different: it is one entry among roughly 820,000 that were all first read within days of each other, and publishing all of them to a search index at once, before most hold more than a day or two of history, is the scaled‑content pattern that got a competitor, Teleteg, penalised in June 2026. That verdict was sticky, and site-level quality classifications are sticky in general — so a channel page starts noindex and graduates the moment its own measurement record earns it.

An entry is offered for indexing when it satisfies at least one of three tests, evaluated fresh on every render rather than decided once and cached:

1. Real history.Three or more subscriber readings — the same count this page’s own “Measurements held” row shows — spanning at least fourteen days from the first to the latest. Either bound alone is easy to satisfy trivially (three readings taken an hour apart; two readings four months apart), so both are required together. This is the path that will eventually cover most of the register on its own, once it has run long enough.
2. An active observation.A duplicate‑content, engagement‑rate, or view/reaction‑decoupling finding — see What an observation is, and is not, above — that is still standing (not withdrawn). A page carrying one has a specific, checkable claim on it beyond a subscriber count, whatever its history depth.
3. An engagement sample. At least one post published in the last 30 days carries a measured view reading. A page in this state renders the Engagement section, and often Reactions, Stars, Advertising or Posts besides — real measured content under the headline number, not just the number restated as a title tag.

Graduation is automatic.There is no request form, no manual review, and no priority queue. The next time an entry’s page is generated after it crosses one of the three thresholds above, it is offered for indexing; the next time a withdrawn observation or an emptied window takes it back under all three, it is withdrawn again. A channel does not keep an indexed page by anything other than continuing to meet one of these three tests.

Measured against the live database, 2026-08-08: of 827,505 register entries, the first test passed zero— the register’s oldest reading is from 2026-08-05, so no entry can yet show fourteen days of span, whatever else is true of it. The second test passed 31,661 entries. The third passed 538,737. Combined, 545,235 entries — about 66% of the register — were index-eligible on that date, almost entirely through the engagement-sample test: this register’s post-reading crawl reaches most channels’ recent posts within days, well before its subscriber-history crawl can accumulate fourteen days of readings on any of them. As the register’s own history deepens past two weeks, expect the first test to take over as the dominant path and the other two to matter mainly for entries the first test has not reached yet.

What an observation is, and is not

An observation is evidence, not a verdict — and today none is graded. Every observation this register holds is recorded at severity zero. Severity zero is not “low risk”: it means the detector that produced it has not yet had its precision measured against hand-checked cases, and until it has, it is not entitled to a grade. That is why nothing on a channel page is coloured as a warning, and why you will not find a score, a rating or a traffic light anywhere on this site.

Three detectors write observations today, and each publishes the evidence a reader would need to disagree with it:

What an observation is not.It is not a fraud finding, not a ranking, and not a statement about anyone’s intent. Duplicate content has at least three ordinary explanations — a channel operating a mirror of itself, an unattributed copy, and two channels independently reposting the same wire story or press release. Our method separates the first two imperfectly and cannot separate the third at all, and every affected page says so in those words. A low engagement rate is most often an audience that reads inside the Telegram app without opening the channel.

Two words we do not use.“Scam” and “fake” appear on this site in exactly one place: where Telegram has applied its own marking to a channel, in which case the label names Telegram as the source. They are never our characterisation of a channel, and no measurement we take is reported using them.

Observations are withdrawn, not archived. Every detector recomputes its entire result set from the underlying posts and metrics rather than adding to it. An observation the current pass no longer supports is marked cleared and disappears from the channel page — it is not kept struck through, and it is not kept as history. We do not go on publishing a claim we have retracted.

Handles a channel named that no longer answer

Every channel occasionally names another handle in a post — a partner, a source, a shop. Some of those handles are vacant today. This register keeps a ledger of every one, keyed by the channel that named it, refreshed continuously by a worker (linkrot.py) that walks the whole mention graph and the whole discovery queue on a repeating pass — a live join was measured at 888ms on the busiest entry, four times this site’s page budget, so the answer is kept current in a table rather than recomputed on every visit.

“Vacant now” is not “died”, and this is the one rule this ledger is built around. A handle a channel names can be a typo, an aspirational name nobody registered, or a channel that was already gone before it was ever mentioned. Measured against the live database: of the handles in this ledger, the overwhelming majority — well over 99% — carry no evidence we ourselves ever saw them resolve to anything real. Those rows say exactly that: references a handle that is not a live channel, never that anything died. Only where we ourselves once read a real page at that handle, or the two-sighting death protocol (see above) positively dated an end for it, does a row carry death language — and even then, most such rows have the first fact but not the second: we saw it alive, we now see it vacant, and that alone is what “evidenced gone” means. A row with an actual confirmed date is rarer still.

The ledger corrects itself in both directions. A newly-vacant, newly-mentioned handle is added; a handle that resolves again is removed — the worker re-derives the whole state on every pass rather than only ever adding rows, so a revival is never left sitting in the ledger as a stale claim.

Posts edited after publishing

Telegram lets an author rewrite a post after it has already been seen, under the same permalink. This register holds a copy of the wording from before an edit, captured the moment our own crawl reads a changed body carrying Telegram’s own editedmarker — see revisions.py’s own header for the full detection rule, including the safeguards against mistaking a change in how we parse a post for a change the channel actually made. A per-channel count of how many posts this has happened to is kept current by a worker (editledger.py) and shown on the channel page.

An edit is detected, never explained.A typo fix, a price update, a correction and a quiet walk-back of an earlier claim are indistinguishable at this layer — all this register can say is that the wording changed, and when. It is not a finding about anyone’s intent.

Disputing an observation, or a number

Message @Mytgregister_bot on Telegram with the handle in question and what you say is wrong. The bot answers look-ups automatically; anything that reads as a dispute is picked up and looked at by a person. Include the specific claim, not just the channel — “the pair at /12345 is a forward and Telegram shows the header” is something we can check in a minute and act on.

What happens next depends entirely on the evidence. If the underlying measurement is wrong, it is corrected at the source and every page derived from it follows within one refresh. If a detector’s reading does not hold up, the observation is cleared and stops rendering. If the measurement is right, it stays, and we will tell you why — the whole point of publishing the evidence is that this is an argument about facts rather than about our judgement.

An observation cannot be removed by request alone, and there is no price for removing one. Corrections are free, permanent and made because they are corrections. Anything else would make every other page here worthless.

The same address takes corrections to anything else on the site: a subscriber count that does not match what Telegram shows, an entry listed under the wrong handle, a channel that has moved. Counts that disagree with Telegram are worth reporting even when the difference looks small — the register is measured, so a disagreement is a bug and not a rounding preference.

Independence

tgregister is not affiliated with, endorsed by, or connected to Telegram. Channels cannot pay to appear here, cannot pay to be removed, and cannot pay to change what a page says. Nothing on this site is ordered by anything other than a measurement.