Telegram New Posts Monitor — Recurring Public Channel Feed

Monitor public Telegram channels and send newly published posts to a spreadsheet, database, research queue or automation workflow. The Actor saves a checkpoint between runs, so you can collect future posts without repeatedly exporting the same history.

No Telegram login, phone number, bot token or Telegram API credentials required. Only content available through public channel previews is collected.

Ready-to-run public task

Open an example below and save your own task in Console. Adjust the visible inputs, check the active Pricing tab and maximum cost per run, then run your copy. Export the dataset as JSON, CSV or Excel after checking the run summary. Reuse that same saved task for later checks; a new task has an independent checkpoint.

Public task	Use case	Expected output
Monitor new public Telegram posts — Starter	Copy a small public-channel feed, then schedule the same saved task	Up to five recent posts on a new checkpoint, then only newer posts; later runs can be empty

The example keeps reset disabled. Copy it as a new task for an independent checkpoint and inspect SUMMARY.errors before treating an empty run as no activity. Actor and platform fees depend on the active Pricing tab; no free recurring service is promised.

Monitor Telegram posts in three steps

1. Add Public channels and choose the New post limit per channel.
2. Keep Return recent posts, then new posts for an initial sample.
3. Save as a new task, run it, and schedule that same task for later collection.

The Console example requests up to five recent posts:

{
  "channels": ["cointelegraph"],
  "initialRun": "emitRecent",
  "maxPostsPerChannel": 5,
  "resetState": false
}

emitRecent returns recent posts only when that channel has no saved checkpoint in the current monitoring state. If it was already monitored, the run returns newer posts instead and can be empty. To get an independent first test, save a new task and run that task.

The first run inspects the latest public page; it is a starting sample, not a historical archive. For one-time extraction, use Telegram Channel Scraper below.

From a Telegram history export to a recurring feed

Channel Scraper exports a snapshot; Monitor keeps a separate checkpoint. There is no automatic transfer of your export position between the two Actors.

1. Choose the same public channels in both tools. For a handoff with overlap, first save a new Monitor starter task, use initialRun: "baseline", keep resetState: false, and run it. Confirm the channels were checked without errors.
2. Export the required history with Channel Scraper. Check SUMMARY and CHANNEL_REPORT for incomplete ranges before treating the export as complete.
3. Run that same Monitor task again, then schedule it at a frequency suited to your channels. Check pending backlog and source errors after every run; do not overlap runs.
4. Merge both datasets using channelUsername + messageId as the unique key. The overlap is intentional. Confirm your destination saved each dataset independently.

This reduces the handoff gap but does not guarantee recovery of posts absent from public previews or beyond the scan limits. Creating the baseline only after your export can miss posts published between those steps. Existing edits, views and reactions are not refreshed by the new-post feed.

Set up a recurring feed

1. Save as a new task with your selected public channels.
2. Set initialRun to baseline to start silently from the current position, or emitRecent to include an initial recent sample. Leave resetState off.
3. Run the saved task once and inspect SUMMARY in its key-value store.
4. Schedule that same task at an interval appropriate for the channels’ posting frequency.
5. Export each run’s dataset or let your integration process it after completion.

A baseline run normally returns zero rows. Later runs can also be empty when there are no new visible posts. Inspect SUMMARY.errors before treating an empty dataset as “no activity”. A successful run status can still contain individual channel or discovery errors.

Example input for a new task that starts with future posts only:

{
  "channels": ["cointelegraph", "the_block_crypto"],
  "initialRun": "baseline",
  "maxPostsPerChannel": 20,
  "maxPagesPerChannel": 5,
  "discoveryKeywords": [],
  "resetState": false
}

When a source error or an insufficient result budget leaves every checkpoint unchanged, the Actor skips rewriting the durable state. SUMMARY.checkpointPersistence reports unchanged or written; each run still exports its private MONITOR_STATE copy and summary. Successful idle checks continue to update the checked timestamp. An explicit reset is persisted even if the public checks fail.

How checkpoints are separated

Each saved task has its own persistent monitoring state. Reuse the same task to continue its feed; a new task creates an independent starting point. Runs started directly from the Actor without a task share the account’s default monitoring state.

Changing initialRun does not replay a channel that already has a checkpoint. An empty input uses the small channel example and also keeps reset disabled. resetState: true starts fresh for the entire current monitoring state. Use it only when intentionally restarting: with emitRecent, previously returned posts can be returned again. Never leave reset enabled in a recurring schedule.

Store results in your destination using channelUsername + messageId as the unique key. Checkpointing reduces repeated collection, but your integration should still deduplicate retries and replays and confirm that it successfully saved the dataset. Do not overlap runs of the same task: their checkpoint writes are not coordinated.

Recover from a storage failure

If saving a channel’s posts cannot be confirmed, its previous checkpoint is retained and the run fails after preserving SUMMARY. Look for POST_STORAGE_FAILED in SUMMARY.errors. Start a new run of the same task to retry. A partial or uncertain write can leave some posts in the failed run’s dataset; deduplicate failed-run and retry results by channel and message ID. Other channels that were successfully processed can retain their updated checkpoints.

The checkpoint is not a receipt from your external integration: confirm that your destination saved the dataset independently. Avoid overlapping runs of the same task.

Handle busy channels and missed cycles

Input	Range	Purpose
maxPostsPerChannel	1–100	Maximum posts returned per channel in one cycle
maxPagesPerChannel	1–20	Maximum public pages inspected per channel with an existing checkpoint

When a cycle cannot finish its backlog, SUMMARY.channelsWithPendingBacklog lists the channels concerned. The previous committed checkpoint is retained while returned IDs are tracked as pending.

If the inspected pages cover the previous checkpoint but there are too many new posts for one cycle, later runs can return the remaining posts. If the page limit cannot reach the previous checkpoint, repeating the same settings may keep the backlog pending. Increase maxPagesPerChannel and consider increasing the post limit or running the task more often.

The pending-ID history is bounded, and very long gaps can exceed the available scan window. This is not a guarantee of recovering every post after an arbitrarily long interruption. For a larger historical recovery, use a dedicated channel-history export and reconcile it with your destination before restarting the monitor’s baseline.

What each row contains

One canonical public Telegram post per row, with available fields such as:

• Source channel, message ID, public post URL and timestamp.
• Text, links, hashtags, mentions and forwarded-post label.
• Displayed views, structured reactions and media references.

Missing public fields may be null or empty. The Actor does not download media files. Counts reflect the public display, including its rounding. Existing posts are not rescanned for changes to their text, views or reactions; this feed detects newer message IDs.

Discover public Telegram channels by topic

Add discoveryKeywords to find candidate public channels by topic:

{
  "channels": ["cointelegraph"],
  "discoveryKeywords": ["crypto news"],
  "maxDiscoveredChannels": 5,
  "initialRun": "baseline",
  "maxPostsPerChannel": 20,
  "maxPagesPerChannel": 5,
  "resetState": false
}

Discovery depends on publicly indexed search results and source availability. It repeats for the entered topics on each run and adds platform usage costs. Candidates can change between runs; channels found once are not automatically added to your permanent input. Review useful candidates and add them to channels for stable monitoring.

countryCode and languageCode influence discovery preferences; they do not verify a channel’s location or classify its posts by language. Keep discovery empty for the simplest and most predictable workflow based on known channels.

Telegram monitoring API, n8n and Make workflows

Use case	Starting point	Destination
News and market announcements	A curated list of public news channels	Analyst review queue or database
Brand and competitor monitoring	Known company or industry channels	Filter returned text in your workflow
Research and AI indexing	Selected public sources	Deduplicated documents with source URLs
Source discovery	A small topic list plus known channels	Review candidates before adding them to monitoring

Use dataset exports or the Apify API with your HTTP client, Make, n8n or another integration. A finished-run webhook can trigger processing; this Actor does not send Telegram or email alerts by itself. The task’s schedule starts collection, while your integration handles delivery and durable storage of the results.

Pricing and run limits

The active plan, effective October 17, 2026 at 11:19:23 UTC, charges $1.80 per 1,000 new posts saved, plus $0.00005 per Actor start event (one per GB of memory, minimum one) and separate platform usage.

At 128 MB, five saved new posts cost $0.00905 in Actor events, plus platform usage. An empty baseline or a cycle with no new posts has no post fee, but still incurs the applicable start fee and platform usage. Discovery can add usage costs; keep it empty when channels are already known. These are event-price examples, not fixed all-inclusive run quotes. Check the Pricing tab for the active rate.

Set Maximum cost per run, a timeout and appropriate collection limits before scheduling. When result billing is active, the Actor checks the remaining result allowance before saving an entire channel batch. If the allowance is too small for that batch, collection stops, SUMMARY.chargeLimitReached is true, and SUMMARY.budgetStop reports the channel, required posts and remaining allowance. That channel's previous checkpoint is retained.

You can lower maxPostsPerChannel or increase the allowed event budget in the next run. An insufficient budget can therefore produce an empty dataset even when new posts exist; inspect the summary. Do not assume the event budget also caps separately billed platform usage: use collection limits and the timeout to control runtime.

If the SDK unexpectedly confirms fewer result charges than the requested batch, the run fails without advancing the affected checkpoint. Deduplicate any partial output on retry. An empty baseline is expected behavior, not evidence of a full historical scan.

Which Telegram Actor should I use?

Your goal	Recommended Actor
Find indexed public posts by keyword	Telegram Keyword Search — discovery with literal matches in text or channel title
Export recent posts or accessible history	Telegram Channel Scraper — date filters and CSV, JSON or Markdown layouts
Collect newly published posts repeatedly	Telegram New Posts Monitor — reuse the same saved task and checkpoint

All three use public Telegram previews without a Telegram login. Private channels and deleted or unavailable posts are outside their coverage.

Limitations

Private channels, groups, invite-only content and pages behind login are unsupported. Deleted posts and content absent from public previews cannot be recovered. Source changes, rate limits, availability and long gaps between runs can reduce coverage. Inspect the run summary and keep independent records of the data your integration has successfully saved.

Frequently asked questions

Does this Actor send Telegram alerts?

It collects a dataset. Connect your own n8n, Make, Zapier or HTTP workflow to deliver alerts; the Actor does not send messages itself.

Why did the first run return no posts?

Future posts only creates an empty baseline. A channel already monitored in this task uses its existing checkpoint. Check SUMMARY.errors and budget limits before treating an empty dataset as no activity.

Does it track edited posts or updated view counts?

No. It detects newer message IDs. It does not refresh edits, views or reactions on posts already collected.

Do I need a Telegram bot or API key?

No. Only public channel content is supported. Private groups and channels cannot be collected.

Coverage and data quality

Read SUMMARY.quality before interpreting an empty dataset. partial means a source error, a known coverage gap or an accepted row missing a required post ID, canonical link or publication timestamp. limited means collection was bounded by a selected limit, budget or collection scope. bounded means the attempted public scan ended without those signals; it does not guarantee every Telegram post is publicly available. These are factual checks, not a score or a promise of complete history.

recordsInspected counts accepted records examined by these checks; it is not a billing counter. missingRequiredFields counts unavailable identifiers, links and dates. optionalFieldsUnavailable counts absent text or views without treating media-only posts as invalid or filling missing values. A zero-row run has no row-level evidence of field completeness. Check existing errors and warnings as well.

An unrecognized public response produces UNRECOGNIZED_PUBLIC_PAGE and retains the affected channel checkpoint; it cannot establish a false empty baseline. A pending backlog is partial coverage until caught up. Initial baselines/recent snapshots are limited to the current public preview, and channelsNotChecked lists unprocessed channels. A successful empty dataset can contain source errors: only interpret it as no observed new posts after checking the summary.

Pagination that stops advancing

If a request for older posts returns the same or a newer page, the Actor stops that channel scan and reports PAGINATION_NOT_ADVANCING in SUMMARY.errors. Coverage is partial. Successfully saved new posts are kept as pending IDs; the previous committed checkpoint remains in place until a later scan catches up. Reuse the same saved task with reset disabled to resume without re-emitting those pending IDs. Increasing the page limit does not resolve a source that keeps returning the same page.

SUMMARY.pagination.pagesRead counts recognized public preview pages inspected, including empty pages and the page that triggered the stop. nonAdvancingPages counts stopped scans. These counters do not include internal HTTP retries and are not billable events or a guarantee of complete coverage.

Post identity and selected channels

The Actor checks each parsed post's channel username before applying the post limit, saving rows or updating a checkpoint. Posts belonging to another channel are excluded and reported as UNEXPECTED_POST_CHANNEL in SUMMARY.errors; SUMMARY.sourcePostsIgnored counts the excluded parsed posts. Coverage is partial. If a nonempty preview contains only posts from other channels, the previous checkpoint is retained and no initial baseline is created. A genuine empty public preview remains a different case.

Valid posts can still contain forwarded text or links to other channels. Those references do not change the identity of the post and are kept in its available fields. Inspect the summary before interpreting an empty dataset as no new activity.

Does zero discovered channels mean there are no matching channels?

Only an explicit no-results response is treated as a verified empty search. An unrecognized or blocked discovery response is reported in SUMMARY.errors with DISCOVERY_UNVERIFIED and partial coverage. A discovery-only run with no channels and a discovery error fails; explicitly configured channels can still be monitored and the run reports the discovery error. Duplicate topics differing only in letter case are searched once per run. For stable recurring feeds, save the useful channel usernames and leave topic discovery empty.