Monitor public Telegram channels with no login, no bot token, no API key. The actor reads each channel's public web preview and returns, per post:

Field	Meaning
views	View count
viral_score	Views ÷ channel median views — how much a post over-performed
is_viral	viral_score ≥ your threshold
engagement_rate	Views ÷ subscribers
matched_keywords, is_alert	Keyword watch — flags posts mentioning your terms
text, posted_at, post_url, media flags	The post itself
subscriber_count, channel_avg/median/max_views, channel_post_count	Channel context

Why this exists

Telegram scrapers dump posts. This is a monitor: it scores each post's virality against the channel's own baseline and raises keyword alerts, so you can watch competitors, track narratives, or trigger a workflow when a topic spikes — without writing the scoring logic yourself. Schedule it and diff runs to catch breakouts as they happen.

Input

{
  "channels": ["durov", "@telegram", "https://t.me/breakingmash"],
  "keywords": ["privacy", "launch"],
  "maxPostsPerChannel": 30,
  "viralThreshold": 2,
  "alertsOnly": false,
  "proxyConfiguration": { "useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"] }
}

• channels — usernames or t.me links.
• keywords (optional) — flag posts containing any term (case-insensitive).
• viralThreshold — × median views to flag is_viral (default 2).
• alertsOnly — with keywords set, return only matching posts.

Output

One record per post with the fields above. Forwards are not exposed by Telegram's public preview; virality is measured from views vs the channel's own median and subscriber base, which captures forward-driven reach.

Access & cost

$0 access — public web preview only. Runs on your Apify account (RESIDENTIAL proxy by default). Pay per post monitored (PPE).

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.