How to Fix Telegram Notifications Not Working on Android?

Why "Telegram Notifications Not Working on Android" Is Rarely a Single Bug

When people set out to fix Telegram notifications not working on Android, they usually arrive with a mental model of one broken switch. The reality is closer to a four-gate pipeline: Telegram has to decide that a notification should be produced, the Android notification channel has to permit it at a usable importance level, the system permission layer has to allow the app to post anything at all, and the device's background-execution policy has to let Telegram learn about the message in the first place. Fail any single gate and the symptom visible to the user is identical — silence. That is precisely why so much advice on this topic contradicts itself: two people with the same symptom can have opposite root causes, and a fix that works on one phone can be useless on the next.

This article takes a performance-and-cost stance rather than a "try these ten tricks" stance. Notifications are a reliability feature with a measurable latency, a measurable delivery rate, and a real price paid in battery and background data, so it makes sense to treat them the way you would treat any other performance problem. Before changing anything, you establish a baseline. Then you apply the cheapest intervention that can plausibly move the metric — call it Plan A — escalate to interventions that carry a cost (Plan B), and finally verify with a repeatable test rather than a feeling that things seem better now.

Everything below is written against the Android client as it exists in the latest version as of this writing. Menu labels shift between OEM skins and Android releases, so where a path is likely to differ, the article says so and gives you the general shape of the screen to search for instead of a hard-coded label.

Feature Positioning: What Telegram's Notification Stack Actually Does — and What It Cannot Do

Telegram is unusual among messaging apps on Android because it does not depend on a single push mechanism. While the app is allowed to keep a long-lived connection alive in the background, messages can reach the device through Telegram's own connection. When the operating system has stopped or frozen the app, the delivery path typically falls back to the platform push channel (Firebase Cloud Messaging, or FCM, Google's push transport for Android apps). This two-path design is the reason Telegram can still notify you on a device where other apps are heavily restricted — and also the reason troubleshooting is not always intuitive.

The persistent connection: fast, but expensive to keep

The persistent connection gives the best latency, because the message arrives on a socket the app already holds rather than being relayed through an external service. Its cost is exactly what Android's battery management exists to prevent: a process that stays awake, holds a network socket, and wakes the radio periodically. Modern Android versions, plus the additional power-management layers that OEMs such as Samsung, Xiaomi, Huawei, Oppo and others add on top, will eventually classify an app and restrict it. When that happens, the fast path disappears silently — no error dialog, no warning, just a message that never arrives.

The system push channel: cheap, but at the mercy of the platform

The FCM path costs almost nothing in battery terms because the platform maintains one shared connection for many apps. In exchange, you give up control: delivery depends on Google Play Services being present, on the device having a usable data connection at the moment of delivery, and on the system not suppressing the notification through channel importance, Do Not Disturb, or a notification cooldown behaviour. On devices without Google Play Services — some Huawei models, and custom ROMs built without the Google stack — the fallback path may not exist at all, and reliability rests entirely on Telegram's own connection surviving the system's background restrictions. That is a structural constraint, not a setting you can toggle away.

Knowing which path your device is currently using changes the diagnostic order. If the persistent connection is alive, a permissions problem will still produce notifications (just possibly late or quiet). If only the FCM path is available, a permissions problem is total silence. The verification section later in this article shows how to tell the two apart empirically.

Define the Metric Before You Touch a Setting

"Notifications are broken" is not a measurable statement, and an unmeasurable problem produces unfalsifiable fixes. Translate it into three axes borrowed from any performance review: speed, retention, and cost. For notifications, speed is delivery latency, retention is the share of messages that actually produce an alert over a long screen-off window, and cost is what you pay in battery, background data, and privacy surface.

Metric 1 — Delivery latency while the screen has been off for a while

Latency here means the wall-clock gap between a sender tapping send and the receiving phone alerting, measured while the receiver's screen has been off long enough for the device to have entered a low-power state. Practically, "long enough" means at least ten to fifteen minutes of no interaction; Doze and app standby behaviour generally need time to engage. A practical target that most users would call "working correctly" is a median in the low single-digit seconds and a worst case that does not stretch into minutes. You set the threshold yourself, but you must set one, otherwise you cannot tell whether a change helped.

Metric 2 — Delivery rate across a full screen-off window

Latency tells you the system is slow; delivery rate tells you whether it is reliable at all. This is the metric that matters most for anyone who depends on Telegram for work. The protocol is simple: send a known number of test messages spread across a day, log for each one whether an alert appeared, and compute the proportion that arrived. A useful personal threshold is that you should not be able to find a reproducible pattern of misses after a long idle period — occasional misses during extreme battery-saving states are a platform behaviour, but a miss every single morning is a configuration defect you can fix.

Metric 3 — Battery and data cost of the reliability you bought

Every intervention that improves metrics 1 and 2 tends to worsen metric 3. Exempting an app from battery optimisation, enabling autostart on OEM skins, or leaving the persistent connection unrestricted all keep the radio and CPU busier. Rather than guessing, read the system's own accounting: the battery usage screen and the per-app mobile data screen both provide a real, device-specific number. Record Telegram's share before and after your changes, over comparable days of usage, and decide whether the reliability gain is worth the drain you observe. The exact magnitude varies enormously with account activity, so no article can hand you the number.

Example: a user who records "one miss per morning" has already localised the failure to an overnight window, which narrows the search to scheduled Do Not Disturb and background restrictions. A user who records "three misses spread randomly across the day" is looking at a different, broader class of cause — typically channel importance or a muted category. The numbers themselves are less important than the pattern they reveal.

Layer 1: Telegram's Own Settings — Plan A

Start inside the app, because these changes are free, instantly reversible, and cannot damage background battery behaviour. The entry point on the Android client is Settings → Notifications and Sounds. Depending on the build and the account you are configuring, this screen presents per-category rows for private chats, groups and channels, along with shared controls for sound, vibration, LED and priority, plus a few system-level event toggles.

Global categories: the first thing to rule out

The most common self-inflicted cause is a category that was muted months ago and forgotten — usually groups, because group traffic is noisy by nature. Walk every category row and confirm that the ones you care about are enabled. Then check the shared sound and vibration settings: a notification that arrives silently and without vibration is functionally invisible when the phone is in a pocket, even though the delivery metric was technically satisfied. If you want to isolate the problem, temporarily set a distinctive sound and enable vibration for the single category you are testing, then disable it again once diagnosis is complete.

Per-chat exceptions: precise but easy to forget

Telegram lets you override notification behaviour per chat. Open the chat, tap the chat title to open its profile, and look for the notifications entry in that screen; from there you can mute the chat, choose a custom sound, or adjust vibration and priority for that conversation alone. This is the right tool when exactly one contact never alerts, and the wrong tool when everything is silent — if every chat is affected, the problem is at a higher layer, and fiddling with per-chat settings will only add noise to your diagnosis.

A small but realistic scenario: a support team runs a 100-member working group plus a separate escalation channel. The group is muted during the day to reduce noise, and someone later mutes the escalation channel by accident while clearing notifications in bulk. The symptom looks like "Telegram is broken" for the two people on call, but the fix is one toggle inside the chat profile. Before escalating to system settings, always confirm at chat level first — it costs thirty seconds and rules out the cheapest class of cause.

The Android notification channel ceiling rule

This is the single most misunderstood mechanic in Android notifications. Modern Android groups an app's notifications into channels (user-visible categories with their own importance level and sound). Once an app creates a channel, the OS settings for that channel set the ceiling for how intrusive the notification can be — heads-up banner, sound, vibration, or just a silent entry in the shade. Telegram's in-app toggles can lower that behaviour or turn it off, but they cannot raise it above what the system channel allows.

The consequence is a specific failure mode: everything looks enabled inside Telegram, yet nothing pops up on screen. The channel importance was set to a low tier at some point — often by the user dismissing a prompt with "silent", or by an OEM skin defaulting new channels low. The fix lives in Android's per-app notification screen, not in Telegram. Reach it via Settings → Apps → Telegram → Notifications and inspect each channel individually.

Multiple accounts, multiple configurations

If you run more than one Telegram account on the same device, configuration is not necessarily shared. Before concluding that a setting has no effect, confirm which account is active — the account switcher is normally reachable from the top of the Settings screen. Changing notification preferences while the wrong account is selected is a classic source of "I already fixed this" confusion, and it produces perfectly reproducible "the fix did nothing" reports.

Layer 2: Android Permissions and Interruption Controls

Once Telegram's own settings are confirmed, the next gate is the operating system. These controls sit above the app: no in-app toggle can compensate for a missing system permission, and no amount of battery tuning will help if the OS is deliberately holding your alerts until morning.

The runtime notification permission on Android 13 and later

Android 13 introduced an explicit per-app notification permission that users must grant, rather than notifications being enabled by default. If that permission is denied — for example because the prompt was dismissed during a rushed app install — the app can post nothing at all, and the failure is total rather than intermittent. The check is quick: Settings → Apps → Telegram → Notifications, and confirm notifications are allowed at the top of that screen before you look at any individual channel.

The diagnostic signature is useful. If the permission is denied, you should see zero notifications from Telegram in the shade over an entire day, including for messages you read seconds after they arrive. If you see notifications for some chats and not others, the permission is fine and you are looking at a channel or per-chat problem instead. Distinguishing these two cases early saves a lot of pointless battery-settings archaeology.

Do Not Disturb, Bedtime mode, and notification cooldown

Do Not Disturb suppresses alerts by design, and on many devices it is scheduled automatically — for example, a bedtime routine that turns on at a fixed hour and turns off with your morning alarm. If your missing notifications cluster around the same hours each day, that correlation is stronger evidence than any settings screen. Check the schedule, and check whether Telegram is in the allowed-apps exception list, which is often configured for calls only.

Recent Android releases have also added behaviours that reduce the intrusiveness of rapid-fire alerts — a notification cooldown that lowers the volume of successive notifications in a short window, and in some builds an adaptive behaviour for apps that send a lot. Empirical observation: when several messages arrive within seconds of each other, only the first tends to produce a full-volume heads-up alert, and the rest arrive quieter. That is platform behaviour, not a Telegram defect, and it is worth verifying before you spend an evening on battery settings. Reproducible check: send five messages with roughly two-second gaps from another device and count how many produce a full alert versus a quiet one.

Layer 3: Battery Optimisation and Background Execution — Plan B

This is where the cost side of the equation becomes explicit. Android's battery management decides how much background freedom an app gets, and OEM skins add their own layers on top. Interventions here are the ones most likely to fix a stubborn latency problem — and the ones most likely to cost you standby battery time.

The three-state battery setting, and what each state means

On recent Android versions, the per-app battery screen — typically Settings → Apps → Telegram → Battery — offers three states. Unrestricted lets the app use background resources without the standard optimisations; Optimized is the system default and applies normal Doze and app-standby behaviour; Restricted severely limits background work and is the most common cause of "notifications only arrive when I open the app". Labels vary slightly between Android versions, but the three-tier logic is stable.

How: change the state to Unrestricted for the account you depend on. Why: it removes the most aggressive class of background restriction, which is usually enough to keep Telegram's persistent connection alive across long idle periods. When not to: do not do this on a device where you are chasing maximum battery runtime, on a shared or corporate-managed device where policy forbids it, or when your measured delivery rate is already good — you would be paying a cost for no measurable gain.

OEM overlays: what to look for when the path does not exist

Most Android phones ship with an additional power-management layer that behaves differently from stock Android. The exact wording changes with every release, so search for the concept rather than the label. On Samsung devices running One UI, the relevant screens historically live under Battery and device care, where a background usage limit list determines which apps are put to sleep. On Xiaomi devices running MIUI or HyperOS, the two levers are usually an autostart permission per app, and a battery-saver mode set to no restrictions. On Huawei's EMUI the equivalent is an app-launch management screen. OnePlus, Oppo, Realme and Vivo devices generally expose their own optimisation toggle plus a battery-optimisation exception list.

Two practical rules apply across all of them. First, OEM layers can override stock Android settings in either direction, so setting Unrestricted in the stock screen and stopping there may not be sufficient. Second, these screens are the single most common place where a user unintentionally re-restricts the app while trying to fix something else — a battery-saving sweep or a "clean up" function can silently revert your exception. After any system update or battery-cleanup action, re-verify that your exception survived.

When switching to a lighter client is the better trade

There is a genuine alternative worth naming: giving up the last increment of reliability in exchange for a much lower cost profile. If your notifications are only slightly late and your battery usage is fine, keeping Optimized while accepting a small latency penalty is a rational choice. Conversely, if you are on call and a missed message has real consequences, Unrestricted plus an autostart exception is the correct trade even if standby drain increases. The mistake is applying the expensive configuration by default to a device and account where the cheap one already meets the threshold you defined in the second section.

Layer 4: Network, Data Saver, and Account-Level Edge Cases

By this point the notification stack, the permissions, and the background policy are all accounted for. What remains is the connectivity layer — and a handful of account-level conditions that produce identical symptoms but have nothing to do with settings at all.

Background data restriction and Data Saver

An app that is forbidden from using mobile data in the background cannot receive messages when Wi-Fi drops, and the resulting symptom — notifications work at home, fail on the move — is often misdiagnosed as a battery problem. Check Settings → Apps → Telegram → Mobile data and confirm background data is permitted. Then check the system-wide Data Saver setting, which can restrict background traffic globally; if Data Saver is on, Telegram needs to be in its unrestricted list. This is a cheap check and belongs in the first pass of any diagnosis, because it explains a whole class of location-dependent failures.

privacy tool, private DNS, and captive portals

Empirical observation: when a privacy tool is active, delivery latency for restricted apps tends to increase and occasionally messages arrive in bursts once the tunnel re-establishes. The same pattern can appear with a custom private-DNS resolver that is slow or unreachable. Verification is straightforward and reproducible: toggle the privacy tool off, repeat your latency test, and compare. If the numbers improve consistently, the network layer — not Telegram — was your bottleneck. Captive portals on hotel and airport Wi-Fi produce a related failure: the device appears connected but the app cannot reach the network until you complete the portal login.

Accounts, sessions, and simple exhaustion of the possibilities

Two account-level conditions deserve a mention because they masquerade as device problems. First, if a session was terminated elsewhere, or the app is signed out, obviously nothing will arrive. Second, if you use multiple accounts, notifications for the secondary account may simply not be configured, since you configured the other one. Neither of these is a settings bug, and both are resolved in seconds once identified — which is the argument for checking them before the deep system layers.

Plan A vs Plan B: A Cost-Aware Decision Table

The table below organises interventions by where they act, what they plausibly buy you, and what they cost. Reliability gain is described qualitatively on purpose: the real magnitude depends on your device, ROM, network and account activity, and any specific percentage quoted in a generic article should be treated with suspicion.

The practical rule: apply rows in order from top to bottom, and stop as soon as your defined thresholds are met. Each row you add past that point is cost without benefit. This ordering is the entire argument for Plan A and Plan B as separate phases rather than a flat checklist.

Monitoring and Validation: Closing the Loop

A fix you have not verified is a hypothesis. The protocol below takes about a day of elapsed time and a few minutes of attention, and it converts your changes from beliefs into observations.

The screen-off delivery protocol

Send messages from a second device or a second Telegram account, spaced across periods when the target phone has not been touched for at least fifteen minutes. For each message, record three things: the time the sender sent it, whether an alert appeared without the phone being unlocked, and roughly how many seconds passed before it did. Do this at several points in the day, and repeat it on the following morning in particular — early-morning failures are the classic signature of overnight background restrictions and scheduled Do Not Disturb.

Expected observable outcome after a successful Plan A fix: alerts appear for all test messages, with the quiet ones still visible in the notification shade. After a successful Plan B fix: the worst-case latency after a long idle window should no longer stand out from ordinary in-use latency. If your recorded results are unchanged, revert the change you just made — an intervention that does not move the metric is pure cost.

Command-line verification for advanced users

If you have ADB (Android Debug Bridge, the developer tool for talking to a device from a computer) available, you can inspect the system's own view of the app rather than inferring it. The Android package name for the Telegram Android client is org.telegram.messenger. These commands are read-only and safe; treat their output as evidence, not as something to blindly modify.

Interpretation guide: the standby bucket command returns the app-standby classification the system is currently applying — a restrictive bucket is consistent with delayed background delivery. The deviceidle whitelist shows which packages are exempt from Doze restrictions. The appops query reveals whether the app's background execution operations have been allowed or denied. The notification dump lists notifications the system has actually recorded, which is the closest thing to ground truth about whether the platform was ever asked to display anything. Note that some OEM builds restrict or omit parts of this output, so treat an empty result as inconclusive rather than as evidence of absence.

Avoiding self-deception in the results

Two traps are worth naming. The first is changing several settings at once and then attributing the improvement to the wrong one; change one layer per test cycle. The second is testing only while the phone is in active use, which naturally produces good results and tells you nothing about the scenario that actually fails. If your problem occurs after hours of idle time, your test has to include hours of idle time — there is no shortcut.

Troubleshooting Matrix: Symptom, Likely Cause, Verification, Fix

The matrix below maps observable symptoms to the most probable layer. Work from the symptom you can actually see rather than from the layer you suspect, because the layers overlap heavily in their visible effects.

• Zero notifications all day, including while using the phone. Likely cause: Android 13+ notification permission denied, or a global mute. Verify: Settings → Apps → Telegram → Notifications shows whether posting is permitted at all. Fix: enable the permission; check for an app-level "silent" state.
• Notifications appear in the shade but never pop up or sound. Likely cause: notification channel importance set to a low tier — the ceiling rule described earlier. Verify: open the per-app notification screen and inspect each channel's importance. Fix: raise importance for the channels you need intrusive.
• Everything works except groups, or except one specific chat. Likely cause: a muted category or a per-chat exception. Verify: chat profile and the per-category rows in Telegram's notification settings. Fix: re-enable the specific row.
• Delays grow the longer the phone sits idle; opening the app flushes a backlog. Likely cause: background restrictions, Doze, or an OEM power-management layer. Verify: battery state screen plus the ADB checks above. Fix: move to Unrestricted and add an OEM autostart exception.
• Works on Wi-Fi, fails on mobile data. Likely cause: background data blocked or Data Saver active. Verify: per-app mobile data screen. Fix: allow background data and exempt from Data Saver.
• Failures cluster at the same hour each day. Likely cause: a scheduled Do Not Disturb or bedtime routine. Verify: the DND schedule screen. Fix: add Telegram to the allowed list, or adjust the schedule.
• Only the first of several rapid messages alerts loudly. Likely cause: platform notification cooldown behaviour. Verify: send five messages two seconds apart and count full alerts. Fix: none required — this is expected platform behaviour, not a fault.

Read the matrix as a routing table, not a diagnosis engine. Several symptoms point at overlapping layers, so the verification step matters more than the guess: confirm the layer before you change it. If two symptoms appear together, handle the one that affects everything first — a missing permission or a muted category will mask whatever else is going on underneath it.

Third-Party Clients, Modified APKs, and the Least-Privilege Rule

Modified or unofficial Telegram clients are a recurring source of notification unreliability, and the reason is structural rather than malicious. The system push channel is tied to the application identity registered with it, so an app that is not the official client does not inherit the official client's push registration. Empirical observation: unofficial builds tend to rely more heavily on their own persistent connection, which makes them disproportionately sensitive to the background restrictions discussed in Layer 3, and they frequently fail after the user applies a battery-saving cleanup.

If you are troubleshooting notifications, the most reliable control is to test on the official client first. That single step removes an entire category of variables. If the official client works and the modified one does not, the problem is not your Android configuration, and no amount of battery tuning will resolve it.

The same least-privilege logic applies to what you are willing to change. Granting an app an exemption from battery optimisation is a real reduction in the operating system's authority over that app. Do it because your measurements justify it, not because a checklist told you to. Similarly, avoid enabling accessibility services or notification-listener access as a workaround for notification problems — those grant far broader visibility than the problem requires, and they are not a legitimate fix for a delivery issue.

Version Differences and Migration Notes

Android's notification model has changed materially across releases, and the advice you follow has to match the platform you are on. On Android 13 and later, the runtime notification permission is the first gate and everything else is secondary. Older releases enabled notifications by default, which is why guidance written for them starts with battery settings and produces confusing results on a modern phone. Android 15 and later add platform-level behaviours that reduce the intrusiveness of rapid notification bursts, which can look like a new bug to someone who just updated.

Telegram's own client changes too: the notification settings screen gains and loses rows over time, and channel names are not guaranteed to be stable. Practically, this means two things. First, when a path in an older tutorial does not exist on your device, look for the same concept rather than the same label. Second, after a major system update or a client update, re-verify that your battery exceptions survived — system updates are a well-known trigger for silently resetting per-app optimisation states.

Applicable and Non-Applicable Scenario Checklist

The techniques in this article are appropriate under some conditions and inappropriate under others. Applying them indiscriminately is how people end up with degraded battery life and no measurable improvement.

Applies well when: you own the device and can change its settings freely; you have a reproducible failure pattern rather than a vague sense of unreliability; you depend on timely alerts for work or on-call duty and can justify the battery cost; you are willing to spend one day running a measurement protocol before and after each change.

Applies poorly, or not at all, when: the device is managed by an employer and settings are policy-controlled — in that case the correct action is a request to IT, not a workaround; the phone is a low-end device where unrestricted background execution would meaningfully cut runtime and the alerts are not time-critical; the problem only appears on unofficial clients; or the failure is actually a network-level issue that no device setting will address. In the first of these cases especially, trying to fight a management policy is both ineffective and potentially a compliance problem.

Best Practices Checklist

Presented as decision rules rather than a to-do list, in the order they should be evaluated.

1. Establish the baseline before changing anything: one latency observation, one delivery-rate observation, one cost observation.
2. Rule out the cheapest causes first — muted categories, per-chat exceptions, whether the correct account is selected.
3. Confirm the system notification permission, then inspect notification channel importance, before touching battery settings.
4. Change exactly one layer per test cycle, then re-run the protocol and record the result.
5. Escalate to battery exemptions only if the metric justifies it, and re-check the exception after any system update or cleanup sweep.
6. Revert interventions that did not move the metric — they are pure cost.
7. Prefer official clients when diagnosing; unofficial builds invalidate the comparison.
8. Never grant accessibility or notification-listener access as a notification workaround.

The order carries as much weight as the individual rules. Moving down the list before exhausting the rows above it usually means paying a battery cost to fix a problem that a single toggle would have solved. Treat the sequence as a filter that narrows the cause before it concentrates the expense.

What to Do Next

The conclusion this article argues for is procedural rather than technical. Telegram notifications failing on Android is not one defect with one cure; it is a four-gate pipeline, and the correct order of operations is to measure, fix the cheapest gate that can explain your symptom, and re-measure. In practice that means starting inside Telegram with per-category and per-chat settings, moving to the Android notification permission and channel importance, and only then paying for battery exemptions and OEM autostart permissions.

Your first action after reading should be the baseline test, not a settings change. Send a handful of messages from a second device across an idle period, note the latency and whether anything was missed, and only then start at Layer 1. If your measurements are already within the thresholds you set, the honest answer is that there may be nothing to fix — and that preserving battery life is the better decision than applying an expensive configuration for a problem you cannot demonstrate.

Future Trends / Version Expectations

Looking forward, the shape of this problem is unlikely to change as much as its surface details. Empirical observation suggests the runtime notification permission and channel importance will remain the primary gates, because both are tied to Android's core notification model rather than to any single release. OEM power-management layers, by contrast, tend to shift wording and menu placement with each generation, so the habit of searching for the concept rather than the label will keep paying off.

It is also reasonable to expect that platform behaviours aimed at reducing notification noise will expand rather than contract, which may make some legitimate alerts quieter by default over time. That does not make them bugs, but it does make a personal baseline more valuable: only a measured reference point lets you distinguish an intended platform behaviour from a genuine configuration defect as the platform evolves.