- Real-time business monitoring is watching the live signals of business health — sales, failed payments, MRR moves, error spikes, new customers, churn — as they happen, not the next day.
- The free ways are real and worth using. Stripe's own notifications, a Zapier ping into Slack or SMS, a menu-bar app like CashNotify, and an MRR dashboard like Baremetrics or ChartMogul each do a genuine job. Each also shows exactly one layer.
- Good alerting is quiet. Few, high-quality alerts with a severity, noise control, and plain-English context beat a firehose of raw log lines every time.
- Single-layer monitoring leaves you blind. The payment tool doesn't know about the error; the error tool doesn't know about the revenue; the MRR dashboard doesn't know which customer or why.
- The fix is the join. When revenue, entitlements, errors, and analytics are joined by identity — the cross-match — one alert can carry who, why, and what's at risk.
- Crossdeck delivers that join to Telegram today — alerts, a Mini App dashboard, hard-data commands, and Prism (ask a follow-up in plain English, answered by your own connected AI off your live numbers). Live now, in private chat.
Definitions used in this guide
Watching a signal as it changes rather than in a delayed report — a sale the moment it clears, an error the moment it fires.
A message sent when a monitored signal crosses a line you care about. Good alerts have a severity and carry context, not just a number.
The payment rails your revenue runs on — Apple, Google, Stripe. Real-time revenue means watching every rail, not just one processor.
What a customer is actually allowed to access after they pay. A revenue event only means something once you can see the entitlement it granted.
Recording exceptions and failures as they happen, with enough context — ideally the affected customer — to know whether they hit a paid path.
Joining revenue, entitlements, errors, analytics, and identity by identity, so one customer's scattered events become one timeline.
Who caused an event. Stamping the actor onto a read, a charge, or an error is what lets an alert say "who," not merely "what."
Crossdeck's plain-English question layer. You ask in words; your own connected AI model answers off your live Crossdeck data — never an estimate.
A change in monthly recurring revenue — a new subscription, an upgrade, a downgrade, or a cancellation — that shifts your trajectory.
What is real-time business monitoring? The short answer
Real-time business monitoring is watching the signals that show whether your business is healthy — new sales, failed payments, MRR moves, error spikes, new customers, and churn signals — as they happen, rather than discovering them the next day in a dashboard. The goal is not to stare at charts all day. It is the opposite: to set up a small number of trustworthy signals so that when something matters, it finds you, and when nothing matters, you are left alone to do the work.
Most founders start monitoring the moment a first real customer arrives, and they start with a notification — Stripe emails you that a payment went through, or the App Store confirms your first sale, and it feels wonderful. That is genuine real-time monitoring, and it is the right place to begin. It also holds whatever rail the money arrives on — App Store, Google Play, or Stripe — because the question is the same on all of them: is money moving right now, and for whom? The trouble comes later, when the business has enough moving parts that a single notification stops being enough context. A payment cleared — from whom, on which plan, and did they actually get access? Revenue dipped this morning — which customer, and was it a cancellation or a card that quietly failed? An error spiked — did it hit a paying customer mid-checkout, or a bot on a page nobody pays for? A notification can tell you what happened. The questions that follow are all about who and why.
That gap is the whole subject of this guide, so it is worth stating plainly up front. Nearly every monitoring tool can tell you what changed on its own layer. Almost none can tell you who it happened to and what is at risk — because that answer lives in the join between revenue, errors, and identity, and no single layer holds it. We will get there. But first the useful, honest part: what to monitor, and the free and standard ways to do it well, because you can get a long way with tools you already have.
What to monitor in real time — the six signals
You do not need to monitor everything. You need to monitor the handful of signals where seeing them sooner changes what you do. For most subscription and app businesses, six cover it.
- New sales. The pulse that something is working. A live sale notification is the cheapest morale in software, and more usefully, a sudden change in the rate of sales — up after a launch, down after a deploy — is one of the fastest signals you have. This is the signal the Stripe sale alert is built for.
- Failed and retried payments. The quietest leak in most businesses. A card declines on renewal, the retry fails, and unless someone is watching, the customer simply disappears at the end of the month. Catching a failed payment early is often pure recovered revenue — the subject of catching a failed payment before it becomes churn.
- MRR moves. Upgrades, downgrades, new subscriptions, and cancellations are the events that actually change your trajectory. A single day's raw revenue can look flat while the composition underneath it shifts. Watching the moves, not just the total, is the heart of monitoring MRR.
- Error spikes. Not every error matters, but an error on a paid path — checkout, sign-in, the thing a customer just paid to use — matters enormously. The signal you want is not "an exception fired," it is "an exception fired for a paying customer," which is why error alerts that name the customer are worth so much more than a raw stack trace.
- New customers. The moment someone becomes a customer is the moment to greet them, onboard them, or simply notice a name you will want to know. A new customer alert turns an invisible database row into a human you can act on.
- Churn signals. Churn is rarely a single event; it is a fade. A failed renewal with no recovery, a sudden drop in usage, a downgrade — each is an early warning that a relationship is cooling while you can still do something about it.
Notice a pattern across all six: each one is more useful when it is attached to a customer. A sale is better with a name. A failed payment is only actionable if you know whose it was. An error spike means something different if it struck a paying customer than if it struck an anonymous crawler. The signals are worth monitoring individually — and they are worth far more monitored together, because a failed payment, a downgrade, and an error are frequently the same customer telling you one story from three angles.
The free and standard ways to monitor — named fairly
Before any paid platform, you can assemble real real-time monitoring from tools you likely already have or can add for nothing. These are good tools. Each does a genuine job, and for many businesses one of them is enough for a long time. Here is the honest map, with what each one is best at.
Stripe's own notifications
The default and the right first step. Stripe can email you and push to its mobile app on successful payments, disputes, and failed charges, with no setup beyond a toggle. If you take one thing from this section, take this: turn these on today. They are free, immediate, and cover the single most motivating signal — money arriving — out of the box. Their limit is that they live inside Stripe: they see the charge, not the customer's error a minute earlier or the entitlement the payment was supposed to grant.
Slack, email, and SMS via Zapier or webhooks
The next rung. Pipe Stripe (or any tool's) webhook events into Slack, email, or SMS with Zapier, Make, or a small script, and you have alerts landing where your team already looks. This is flexible and cheap, and it is genuinely how a lot of good teams run for years. The catch is that you are wiring one layer at a time — a Stripe zap here, an error-tool zap there — and nothing joins them. You end up with several channels of single-layer pings and a human doing the correlation. We wrote about doing this well, without drowning, in setting up Slack and email alerts for production errors.
Menu-bar and desktop apps
Tools like CashNotify put live Stripe payments in your menu bar — a quiet, always-there feed of money moving. They are lovely for exactly that: an ambient sense of the revenue pulse without opening a dashboard. If your need is "let me feel the sales happen," a menu-bar app is a clean answer. Its scope is, by design, the payment layer on one processor. If you have outgrown that scope, the CashNotify alternative comparison walks through where the line falls.
MRR dashboards
Baremetrics, ChartMogul, and MRR.io turn raw Stripe data into the recurring picture — MRR, growth, churn, LTV — and several offer real-time or near-real-time notifications on top. For understanding the shape of a subscription business, these are excellent and purpose-built, and we say so plainly. Their focus is the revenue and subscription layer; they are not error monitors or product-analytics tools, and they generally see the processors they connect to rather than every rail plus the app behaviour around a customer. If you are weighing one up, the Baremetrics alternative and the wider survey of Stripe revenue monitoring tools lay out the trade-offs without spin.
Put together, these tools give you a workable real-time setup for free or close to it. That is not a grudging admission — it is the point. Start here. The question this guide exists to answer is what you reach for when the free stack starts to strain: when you have five channels of single-layer pings and still cannot answer "who was this, and what's at risk?" in one read.
How to monitor Stripe revenue in real time
Because it is the most-searched version of this question, here is the direct, tool-agnostic answer. To monitor Stripe revenue in real time, you subscribe to the revenue events as they happen and route them to a channel you actually watch — then, ideally, attach each event to the customer it belongs to. Concretely, there are three levels, and most businesses climb them in order.
- Turn on Stripe's native notifications. Successful payments, failed charges, and disputes, to email and the Stripe mobile app. Zero engineering, immediate, free. For many, this is enough for the first stretch.
- Route the events somewhere shared. Send Stripe webhook events into Slack, SMS, or a dashboard so the whole team sees the same live picture and you are not the single point of awareness. This is where seeing app revenue in real time before App Store Connect catches up becomes possible — you are reading the event stream, not waiting on a store report.
- Join each event to the customer. The level most setups never reach. A payment event on its own is a number; the same event resolved to a customer identity — with their plan, their entitlement, and any error they just hit — is a situation you can act on. This is the join we will spend the rest of the guide on.
One accuracy note worth holding onto, because it separates a trustworthy setup from a misleading one: real-time revenue should be recognised, live data, not an estimate. A number that says "roughly this much, probably" trains you to ignore it. A number that comes straight from the event — this charge, this customer, right now — is one you can build a habit around. We treat this distinction at length in the complete guide to app revenue intelligence.
How to see your App Store revenue in real time
Stripe is only one rail. If you sell on the App Store, the same question — is money moving right now? — runs into a different obstacle: App Store Connect's own reporting lags. The Sales and Trends dashboard is delayed by roughly a day and often more, and payments and proceeds are reported on a monthly cycle. So you can wait 24 to 72 hours or longer to confirm from Connect alone that a sale even happened. That wait is the real, searched pain — and it is not a knock on Apple, it is simply what that reporting surface is built for.
The part most founders miss is that Apple already emits a real-time signal — it is only the dashboard that is slow. StoreKit 2 transactions and App Store Server Notifications v2 report a purchase, a renewal, or a cancellation as it happens. Crossdeck ingests and verifies those events, so it knows about a sale in near-real time and can send a joined alert to Telegram before the Connect dashboard catches up. To be exact about the mechanism: Crossdeck reads and verifies the signal Apple already sends — it does not speed up Apple's payouts or reporting, and it does not need to.
Because the purchase is verified and joined to the customer, an App Store alert carries the same who, why, and what's at risk as a Stripe one — which customer, on which product, and whether their entitlement is now active. We cover the mechanism in depth in seeing app revenue in real time before App Store Connect catches up, the live-alert angle in App Store Connect real-time revenue, the first-sale signal in the App Store sale alert, and the recurring shape in App Store subscription MRR in real time. Google Play sits on the same path — its equivalent real-time signal is on the roadmap, not shipped yet.
How alerting should actually work
Monitoring is the continuous picture; an alert is the message that fires when the picture crosses a line. The difference between a monitoring setup people trust and one they mute comes down almost entirely to the quality of the alerts. Three properties separate the two.
Severity. Not every event deserves the same volume. A failed payment on a large annual account and a single transient warning should not arrive looking identical, or you will learn to treat both as background. A good setup grades its alerts, so the loud ones are rare and mean something and the quiet ones can be batched or left for later. Severity is what lets you glance at an alert and know, before reading it, roughly how much of your attention it deserves.
Noise control. The fastest way to kill a monitoring habit is to alert on everything. One message per error row, per minor fluctuation, per bot request, and within a week the channel is muted and the one alert that mattered dies in the scroll. Good alerting groups related events, fires on trends rather than every occurrence, and stays quiet until something genuinely crosses the line. The measure of a healthy alerting setup is how little it interrupts you — silence is a feature. We wrote a whole piece on keeping error alerting from becoming a firehose in alerts without drowning your team.
Plain-English context. An alert should be readable by a human in one glance, not decoded. "Payment failed" is a fact; "Renewal failed for a customer on your top plan — card declined, entitlement lapses tonight unless it recovers" is a situation. The second one tells you what happened, to whom, and why it matters, in language you do not have to translate. This is what plain-English error summaries are about, and the same principle applies to every kind of alert: context, in words, is what turns a notification into a decision.
Hold these three together and you get the thing you actually want from monitoring: to be interrupted rarely, and when you are, to be interrupted well — with enough in the message to act without opening five other tools. Which raises the obvious question: why do so many alerts fail that test and make you open the other tools anyway?
Why single-layer monitoring leaves you blind
The reason a typical alert makes you go digging is structural, not a flaw in any one tool. Each monitoring tool is excellent at one layer and knows nothing about the others. The payment tool watches payments. The error tool watches errors. The MRR dashboard watches the recurring number. The analytics tool watches behaviour. Every one is correct within its own walls — and no wall has a window into the next one.
Walk a single real incident through this stack and the blindness becomes concrete. A customer on a paid plan tries to upgrade. A bug throws an error at the moment they submit. The charge fails. They give up and, a week later, cancel. Now look at what each tool saw:
- The error tool saw an exception. It does not know the person throwing it was a paying customer mid-upgrade, so it files the error next to a thousand harmless ones.
- The payment tool saw a failed charge. It does not know an error caused it, so it looks like an ordinary decline to retry later.
- The MRR dashboard saw the number dip a week later at cancellation. It does not know the cancellation traces back to a bug on upgrade day, so the cause is invisible and the churn looks like a customer who simply left.
Three tools, three true facts, one story none of them can tell. The payment tool doesn't know about the error; the error tool doesn't know about the revenue; the MRR dashboard doesn't know which customer or why. You, the human, are the only integration point — correlating three dashboards by hand, usually after the customer is already gone.
| Tool | What it monitors | What it can't see | Its view of the customer |
|---|---|---|---|
| Payment / Stripe notifications | Charges, refunds, disputes | The error that caused a failed charge | A charge, not a person |
| Menu-bar app (e.g. CashNotify) | Live payments on one processor | Errors, entitlements, other rails | A payment event |
| MRR dashboard (e.g. Baremetrics, ChartMogul) | MRR, churn, LTV | Which customer moved the number, and why | An aggregate, mostly |
| Error monitor | Exceptions and stack traces | Whether the error hit a paying customer | A session or device |
| Analytics | Events and funnels | The revenue and errors around a session | An anonymous ID |
| Joined by identity | All of the above, on one timeline | — | One customer, with revenue, errors, and behaviour attached |
Look at the last column. Every tool has a different notion of the customer — a charge, a payment event, an aggregate, a session, an anonymous ID — and none of them is the customer. That fragmentation is the reason a single alert can never carry the whole story: the story is spread across five identities for one person, and nothing joins them. This is the same structural failure a subscription business hits everywhere its data lives in separate tools, which we mapped in the complete guide to app subscription analytics. The data exists. The join does not.
The join: an alert that carries who, why, and what's at risk
The fix for single-layer blindness is not a sixth tool watching a sixth layer. It is a layer that sits above the others and joins them. Crossdeck is that layer — the app intelligence layer — and the way it works is the cross-match: it joins revenue across rails, entitlements, errors, analytics, and identity by identity, so a customer's scattered events collapse into one timeline. Once revenue and errors and behaviour are resolved to the same person, a single alert can finally carry the three things a single-layer alert never can: who, why, and what's at risk.
Return to the failed upgrade. On a joined timeline, that incident is not three disconnected facts — it is one event with a name on it: this customer, on this plan, hit this error while upgrading, the charge failed as a result, and their entitlement is now at risk. That is a single alert you can act on immediately, because everything you would otherwise go digging for is already in it. The error is not next to a thousand harmless ones; it is flagged because it struck a paying customer on a paid path. The failed charge is not an anonymous decline; it is tied to the bug that caused it. The churn risk is visible now, on upgrade day, not a week later at cancellation when it is too late.
| Question | Single-layer alert | Identity-joined alert |
|---|---|---|
| What happened? | Yes — on one layer | Yes — across layers, in order |
| Who did it happen to? | No — a charge or a session | Yes — a named customer |
| Why did it happen? | No — the cause is in another tool | Yes — the error and the charge are linked |
| What's at risk? | No — the revenue impact is elsewhere | Yes — the entitlement and MRR at stake |
| Can you act from the alert alone? | Rarely — you open other tools first | Usually — the context is already there |
This is the moat, stated as plainly as we can: every other tool tells you what; the join tells you who, why, and what's at risk — because it holds identity, revenue, and errors in one hand. It is not that the single-layer tools are wrong. They are right about their layer. The join is simply the thing none of them was built to do, and it is where the answers you actually need to act on live. The same engine underneath is what powers verified, cross-matched entitlements and the error-to-revenue link we compared in error monitoring that knows about revenue.
Monitoring from your phone: the Crossdeck bot on Telegram
A join is only useful if it reaches you where you already are. For real-time monitoring, that place is increasingly a phone, and Crossdeck delivers the joined picture to Telegram — @Crossdeck_bot — live today, in private chat. Four things run there now, and it is worth being precise about each, because they are what turns the join from a dashboard feature into something you can run your business from.
- Real-time alerts. The joined alerts above, delivered to Telegram as they happen — a sale, a failed payment, an error on a paid path, a new customer — each one already carrying who, why, and what's at risk. Because they are joined, they clear the bar from the alerting section: severity, context, and a reason to care, in one read.
- A Mini App dashboard. Tap into a Mini App inside Telegram for the live picture — revenue, errors, people — without leaving the app the alert arrived in. You sign in to the dashboard with Telegram, so there is no separate login to manage.
- Hard-data commands. Ask for the numbers directly:
/revenue,/errors,/people,/status. Each returns live Crossdeck data — the recognised number, right now — never an estimate or a guess. This is the same discipline as everything else in the guide: the figure is real, or it is not shown. - Prism — ask in plain English. With
/prism, you ask a follow-up question in words and get an answer off your live Crossdeck data. The important detail, and the one that makes it trustworthy: Prism runs on your own connected AI model, with your own key. Crossdeck does not run AI on your data or train on it; you connect a model in the Prism tab first, and from then on your model answers your questions against your live numbers. Ask "which customers on the top plan hit an error this week?" and the answer comes from the join, in plain language.
Two honest notes to keep expectations exact. First, /prism is not zero-setup — you connect a model in the Prism tab once before it can answer; after that it is ready. Second, this all runs in private chat by default, with single-use tap-actions on the alerts; shared team and group-chat monitoring is on the roadmap, not shipped today. What is live now is the whole single-operator loop: joined alerts, the Mini App, the commands, and Prism — enough to run your business from your phone. If that is the part you want, running your business from your phone covers it in full, and getting Stripe error alerts in Telegram is the step-by-step setup.
A walkthrough: one alert, one plain-English question
Here is the whole thing in one illustrative sequence — invented customer, invented numbers, but the exact shape of how joined monitoring plays out on a phone.
A Telegram alert lands. Not "a payment failed." Instead: a renewal on your top plan just failed on a declined card, for a customer who has been with you a while, and their entitlement lapses tonight unless it recovers. The alert already carries who, why, and what's at risk — because the revenue event, the customer identity, and the entitlement are joined. You read it once and understand the whole situation.
You want a little more before deciding. Rather than opening a dashboard, you reply in the same chat with /prism and ask, in plain English, "has this customer hit any errors this month, and what's their usage trend?" Your own connected AI model answers off your live Crossdeck data: no errors, usage steady until this week, then a drop that lines up with the failed renewal. That is a customer worth a personal recovery email, not an automated dunning sequence — and you knew it in two taps, from your phone, without correlating three tools by hand.
The point of the walkthrough. Every step used the join. The alert was actionable because revenue and identity and entitlement were one thing. The follow-up was answerable because errors and usage and revenue sat on the same timeline, and Prism let you ask across all of it in words. No single-layer tool could have produced either the alert or the answer, because neither the alert nor the answer lives on any single layer. This is what "monitor revenue and errors together" actually looks like when it is done as one system instead of five. The natural-language side of it has its own guide in asking your business data in plain English.
How to start with real-time business monitoring
Start small and free, then add the join when the free stack strains. A sensible order:
- Turn on the free signals today. Stripe's native notifications and a menu-bar app if you like the ambient feed. This is real monitoring and costs nothing — do not skip it waiting for something fancier.
- Route the important events to one channel. Get sales, failed payments, and error alerts landing where you and your team already look, rather than scattered across five tools' own inboxes.
- Add an MRR view. An MRR dashboard for the recurring shape, so you are watching moves and not just the daily total.
- Notice the strain. The moment you find yourself opening three tools to answer "who was that and what's at risk?", you have outgrown single-layer monitoring. That is the signal to add the join.
- Join it by identity, and put it where you are. Bring revenue, entitlements, errors, and analytics onto one customer timeline, and route the joined alerts — plus commands and plain-English questions — to a phone-native channel like Telegram, so one alert carries the whole story.
The through-line of this guide is simple. Real-time monitoring is not about watching more; it is about being told the right thing at the right moment, with enough context to act. The free tools get you a real version of that on their own layers. The join is what makes a single alert enough — who, why, and what's at risk, in one read, from your phone. You can see how the cross-match works on cross-deck.com, ask your own numbers a question with Prism, or start free and wire the first joined alert into Telegram today.
Frequently asked questions
What is real-time business monitoring?
Real-time business monitoring is watching the signals that show whether your business is healthy — new sales, failed payments, MRR moves, error spikes, new customers, and churn signals — as they happen, rather than discovering them the next day in a dashboard. Done well, it does more than fire a notification: it tells you which customer is affected, why the number moved, and what is at risk, so a single alert is enough to act on without opening five other tools.
How do I monitor Stripe revenue in real time?
The simplest free way is to turn on Stripe's own email and mobile notifications for successful payments and disputes, or to pipe Stripe webhook events into Slack, email, or SMS with a tool like Zapier. A menu-bar app such as CashNotify shows live Stripe payments on your desktop, and an MRR dashboard such as Baremetrics or ChartMogul tracks the recurring picture. Each of these shows the payment layer. To also see who paid, what they can now access, and whether they hit an error, you need the payment event joined to the customer's identity across your other tools.
What should a business monitor in real time?
Six signals cover most of it: new sales (the pulse that something is working), failed and retried payments (recoverable revenue that leaks quietly), MRR moves (upgrades, downgrades, and cancellations that change your trajectory), error spikes (especially ones on a paid path), new customers (the moment to greet or onboard someone), and churn signals (a failed renewal or a sudden drop in usage). The point is not to watch all six in separate tools; it is to see them together, because a failed payment, a downgrade, and an error are often the same customer telling you one story.
What is the difference between an alert and monitoring?
Monitoring is the continuous picture of your business; an alert is a message that fires when something in that picture crosses a line you care about. Good monitoring produces few, high-quality alerts: each one has a severity, is filtered so you are not drowned in noise, and carries plain-English context — what happened, to whom, and why it matters — rather than a raw log line. An alert that names the customer and the stakes is worth a hundred that just say a number changed.
Why isn't a single monitoring tool enough?
Because each tool sees one layer and stops there. Your payment tool knows a charge succeeded but not that the same customer hit a checkout error a minute earlier. Your error tool knows an exception fired but not that it struck a paying customer mid-upgrade. Your MRR dashboard knows the number dropped but not which customer or why. Every single-layer tool can tell you what happened on its layer; none can tell you who it happened to and what is at risk, because that answer lives in the join between revenue, errors, and identity that no one layer holds.
Can I monitor my business from my phone?
Yes. Real-time alerts to a phone-native channel like Telegram, email, or SMS let you keep a light watch without living in a dashboard. Crossdeck goes a step further by delivering alerts, a Mini App dashboard, and hard-data commands to Telegram, so you can check revenue, errors, and people from your phone and ask a follow-up question in plain English — all from where the alert landed.
How do I reduce alert noise?
Set severities so that a failed payment on a large account does not look the same as a trivial warning, group related events instead of firing one per row, alert on trends rather than every single occurrence, and make sure each alert carries enough context to be acted on or dismissed in one read. Noise is what happens when everything is urgent; a monitoring setup earns trust by being quiet until something genuinely matters.
What is real-time revenue tracking?
Real-time revenue tracking is seeing money moving as it moves — a sale the moment it clears, a failed payment the moment it fails, an MRR change the moment it lands — rather than waiting for an end-of-day report or for App Store Connect to catch up. It is most useful when the number is tied to a customer, so a revenue move arrives with a name and a reason attached instead of as an anonymous figure on a chart.
Does monitoring revenue and errors together actually help?
It is often the whole game. A revenue drop and an error spike that look like two unrelated incidents are frequently one event — a broken checkout, a failing renewal, a bad deploy on a paid path. Monitoring them in the same place, joined to the same customer identity, is what turns two half-signals into one clear cause. Watching them in separate tools leaves you correlating by hand, usually after the damage is done.
How does Crossdeck monitor a business in real time?
Crossdeck is the app intelligence layer: it joins revenue across rails, entitlements, errors, analytics, and identity by identity — the cross-match — so a single alert carries who, why, and what is at risk. It delivers that live to Telegram today: real-time alerts, a Mini App dashboard, hard-data commands (/revenue, /errors, /people, /status), and Prism (/prism), which lets you ask a question in plain English and have your own connected AI model answer off your live Crossdeck numbers. Every figure comes from your live data, never an estimate.
See it live on your own numbers
Connect your rails and get real-time alerts that name the customer, the plan, and the money — plus a Mini App and plain-English answers, live in Telegram. Free to start.