How to fix Telegram notifications not working on Android and iOS?

What "not working" actually means before you change a single setting

People searching for how to fix Telegram notifications not working usually describe four completely different failures with the same sentence. One person means no banner ever appears. Another means the banner appears but the phone stays silent. A third means messages arrive twenty minutes late. A fourth means everything works until the app is closed, at which point the phone goes dark. These are not variations of one bug; they are failures at four different stages of a delivery chain, and each stage has its own settings page. Naming the failure accurately is therefore not pedantry — it is the step that decides which of the sections below you actually need to read.

Treating the problem as a single switch to flip is why so many people spend an hour toggling things at random. The efficient approach is to identify which stage is failing, touch only that stage, and then verify with a repeatable test rather than a feeling. That discipline matters even more if you are responsible for a team account or a regulated device, where "it works now" is not evidence — you need something an auditor or a colleague can reproduce.

The five layers every Telegram notification passes through

A message reaches your lock screen through a chain: Telegram's servers decide that a push is warranted; a platform push service carries it; the operating system applies delivery rules; the Telegram app applies its own per-chat and per-category rules; and finally the notification is presented with or without sound and preview text. Break the chain at the first two layers and nothing appears at all. Break it at the third and notifications may be silently swallowed by a Focus mode or a battery policy. Break it at the fourth and only specific chats go quiet. Break it at the fifth and you get a silent banner or the generic "You have a new message" line.

On iOS, the transport layer is Apple Push Notification service (APNs), the system that delivers push messages to Apple devices. On Android, most builds installed through Google Play rely on Firebase Cloud Messaging (FCM), Google's push service. Builds distributed outside Google Play, or installed on devices without Google Play services, may instead keep a background connection of their own. Empirical observation: those alternative builds tend to behave differently around battery savers, because the operating system sees them as an app that wants to stay connected rather than an app that receives occasional pushes. If your build came from somewhere other than a mainstream app store, note that fact before you start — it changes which fixes are relevant.

Keeping the layer model in mind has a practical payoff: it tells you when to stop. Once a notification is demonstrably delivered by the transport and then suppressed by the operating system, further changes inside Telegram cannot help, and every extra toggle you flip only makes the next diagnosis harder.

Mute versus system suppression: the distinction that saves the most time

A muted chat still receives messages. Telegram simply stops presenting them as alerts, and on most builds the unread counter still updates. That is a crucial difference from a notification that was never delivered: muting is an app-level decision that you can reverse in two taps, while system suppression is imposed by the operating system and often leaves no trace in the chat. Confusing the two is what turns a two-tap fix into an afternoon of searching.

You can separate the two in under a minute. Open the chat in question, check whether the bell icon in the chat header is crossed out, and compare with a chat you know is not muted. If a muted chat produces a silent entry in the chat list the moment you open the app, the transport layer is fine and you are looking at an app-level rule. If opening the app reveals a message that arrived long ago but never triggered anything, the problem sits above the app, in the operating system or the push service. Reaching that conclusion before you open Settings is the difference between a five-minute fix and an afternoon of guessing.

A short triage path: symptom to layer in ninety seconds

The table below maps the symptom you actually observe to the layer most likely responsible. It is deliberately coarse — the goal is to eliminate three layers so you can concentrate on the fourth. Use it before you read the platform-specific sections that follow.

Observed symptom	Most likely layer	First thing to check
Nothing appears, even with the app closed, from any chat	System permission or push transport	System-level notification permission for Telegram
Notifications arrive only when the app is open	Background restrictions or battery policy	Battery optimisation / background app refresh
Banner appears, no sound or vibration	Presentation layer or channel sound	Notification channel sound (Android) or system sound (iOS)
Only one chat is silent	Per-chat mute or exception	Chat header bell icon
Notifications stop during certain hours or locations	OS automation: Focus, Do Not Disturb, scheduled summary	Focus / DND schedules
Delayed by minutes, then several arrive at once	Battery saver throttling the background connection	Unrestricted battery usage for Telegram

Notice that five of the six rows have nothing to do with the chat you care about. That is the point of the table: most notification complaints are resolved by looking at the phone, not the conversation.

If your symptom does not match a row cleanly, that mismatch is itself informative. It usually means two layers are involved at once — a system restriction that hides the alert and a per-chat mute that would have silenced it anyway — and in that case it is worth clearing the outermost layer first, because a fix at an inner layer cannot be observed while an outer one is still blocking delivery.

Use case gallery: five situations, five different priorities

Generic advice tends to be useless because the acceptable failure mode differs by situation. For a personal chat, a delayed message is an annoyance. For an operations channel, a delayed message is an incident. The gallery below sketches five realistic scenarios and states what each one actually requires, so you can pick the one that resembles your setup and skip the rest. The fixes overlap, but the priorities do not, and it is the priority that determines what you change first.

Case 1 — Community manager watching a channel with six-figure subscribers

Imagine a channel with roughly a hundred thousand subscribers that publishes a handful of posts per day, with three administrators spread across time zones. The people who need alerts are the admins, not the subscribers: they must know quickly if a scheduled post failed or if the channel is being spammed. Their failure mode is not "no sound" but "alert fatigue", which is the practical opposite problem. Muting the channel and unmuting only the admin group through a Telegram notification exception is the standard pattern here. The reasoning matters: exceptions let you keep a channel silent for the group while still receiving direct mentions and replies, which are usually the only messages that require action.

Case 2 — On-call engineer receiving alerts from a bot

A bot that forwards monitoring alerts into a private chat or a small group is a common setup. Here the requirement is near-real-time delivery, and the most common failure is not Telegram at all — it is the phone deciding that the Telegram app has been idle too long and freezing its background activity. The fix is usually an operating-system setting, not a Telegram setting: allow unrestricted battery usage for the app, and disable any vendor "sleeping apps" behaviour. Working hypothesis worth testing rather than assuming: apply the change, then have a colleague send a test alert while your screen has been off for a while, and compare arrival time before and after. If the improvement is visible, the battery policy was the cause.

Case 3 — Shared support device in a regulated environment

When the same phone or tablet is used by several support agents, the interesting question is not whether notifications appear but who can see them. A lock screen preview that shows message text is effectively an uncontrolled disclosure channel. Turning off message preview on that device — so notifications read simply "You have a new message" — is a data-minimisation measure, and it can be documented. Whether you also need to disable notification grouping depends on whether grouped stacks reveal sender names on your platform; check on the actual device rather than trusting a generic guide.

Case 4 — Personal user whose one important chat has gone quiet

This is the most common case by volume and the simplest: the chat was muted at some point, often after a noisy conversation, and the mute was never removed. Telegram's mute is silent about itself, which is why people forget. The check is a single look at the chat header: if the bell is crossed out, tap it and choose to unmute. If you muted with a duration rather than indefinitely, the setting expires on its own, which can create the confusing impression that notifications "fixed themselves" without any action.

Case 5 — Managed device where notification policy is not yours to change

On a device enrolled in mobile device management (MDM), some notification behaviour may be controlled by a profile rather than by you. Empirical observation: on managed devices, settings pages sometimes appear greyed out or revert after a restart. If that happens, the honest answer is that the change must be made by whoever administers the device. Attempting to work around it by reinstalling the app on a personal profile is both likely to fail and probably against your organisation's policy — a boundary worth stating plainly rather than quietly testing.

Android: the shortest paths, in the order that actually helps

Android gives you two places to configure the same outcome — inside the Telegram app and inside the system settings — and they do not always agree. The order below goes from the app outward, because app-level settings are the ones most often changed by accident. Menu labels shift between versions and vendor skins, so look for the closest equivalent rather than an exact word match; the paths below reflect the latest version as of this writing.

Step 1 — App-level categories and the global sound switch

Open Telegram and go to Settings → Notifications and Sounds. On Android this screen is split into categories such as Private Chats, Groups and Channels, each with its own sound, vibration and related options. A frequent cause of "silent but visible" notifications is one of these categories being set to a silent sound or to a low priority while another category is fine. If you only care about one type of conversation, adjust that category and leave the others alone — changing everything at once makes it impossible to tell which change helped.

This screen is also where the message preview option lives. Turning it off reduces the information that appears outside the app, which is the first thing to do on any device that is not exclusively yours. The trade-off is real: with preview off you must open the app to know whether a message matters, which slows down response in time-critical setups. Decide which cost you prefer before you change it, not after.

Step 2 — System notification permission and the channel-level sound

Go to Settings → Apps → Telegram → Notifications on the phone. Confirm that notifications are allowed at all. On Android versions that require a runtime permission for notifications, this is the switch that decides whether anything can be shown. If it is off, no amount of in-app configuration will help.

Below that, Android organises notifications into channels — named groups such as private chats, groups, channels and other — each with its own importance and sound. There is a well-known behaviour here worth stating as an empirical observation with a reproducible check: once a channel has been created, changing the sound inside the Telegram app may not change the sound the system actually plays, because the channel keeps the sound it was created with. To verify on your own device, long-press a Telegram notification, tap the settings icon that appears, and look at the channel's sound. If it differs from what you selected in the app, set it on the system page. If you want a clean slate, deleting the channel in system settings and letting Telegram recreate it is one option — but note that this resets your customisation, so treat it as a last resort rather than a first move.

Step 3 — Battery optimisation, the most common cause of "only when I open the app"

If notifications arrive only after you unlock the phone and open Telegram, the operating system is almost certainly restricting the app's ability to run in the background. The path is Settings → Apps → Telegram → Battery (the exact wording varies: some builds say "App battery usage", others "Battery optimisation"). Set Telegram to unrestricted. The rationale is straightforward: an unrestricted app may hold a background connection and receive pushes promptly, at the cost of some battery. The boundary is equally straightforward: on a phone with a small battery that you charge once a day, unrestricted apps add up, so apply this selectively rather than to every app that asks.

Many manufacturers add a second layer on top of Android's own policy — often described as sleeping apps, deep sleeping apps, autostart managers or protected apps. These are real, publicly documented vendor features, but their names and locations differ from brand to brand, so a generic path would be misleading. The reproducible approach is to search your device settings for the brand's battery or app-management section and look for whether Telegram is listed as restricted. Verification: after changing the setting, keep the screen off for several minutes, then have someone send you a message and note whether the notification arrives before you touch the phone.

Step 4 — Background data and data saver

A less obvious culprit is restricted background data. If Telegram is blocked from using mobile data in the background, notifications will still arrive over Wi-Fi and appear to fail only when you leave the house — a pattern that is easy to misread as random. Check Settings → Apps → Telegram → Mobile data and Wi-Fi (wording varies) and make sure background data is permitted. If your device has a system-wide data saver, confirm Telegram is in the exception list. This is a configuration change with no downside other than data usage, which makes it one of the cheapest things to rule out.

iOS: the shortest paths, from permission to Focus

iOS presents a simpler surface than Android but a more aggressive one: the system is more willing to suppress notifications on your behalf, and it does so without telling the app. That is why a Telegram setting can look correct while notifications still do not appear. Work through the following in order.

Step 1 — In-app notification settings

In Telegram, open Settings → Notifications and Sounds. On iOS this screen exposes category toggles, in-app sound and vibration options, and the message preview setting. If your symptom is "banner but no sound", the in-app sound option is the first thing to check, because the platform can be configured to play nothing while still displaying the banner. If your symptom is "nothing at all", this screen is unlikely to be the cause and you should move outward to the system settings.

Step 2 — System notification settings for Telegram

Open the phone's Settings → Notifications → Telegram. Confirm that Allow Notifications is on, then check the delivery destinations — lock screen, notification centre, banners — because a notification can be delivered to the notification centre yet never appear as a banner, which many people experience as "no notification". Also check Sounds and Badges. If Show Previews is set to "When Unlocked" or "Never", text will be hidden even though notifications themselves work; that is a privacy setting, not a fault, and it is the right default on any device that leaves your possession.

Step 3 — Focus, scheduled summaries and quiet delivery

Focus modes are the single most common reason for silent gaps that follow a schedule. Check Settings → Focus and inspect every mode you have configured, including any that switch automatically by time or location. A Focus mode can allow notifications from selected people and apps only, and Telegram is frequently not on that list. Separately, check whether Telegram is subject to Scheduled Summary delivery, which batches notifications and can make them appear much later than they were sent. Finally, an individual notification can be delivered quietly rather than prominently; if one chat behaves differently from another, compare the notification's own detail view rather than the app settings.

Step 4 — Background App Refresh and Low Power Mode

Check Settings → General → Background App Refresh and confirm it is enabled for Telegram. This does not block the push notification itself — APNs delivers that regardless — but it affects how quickly the app can fetch and display related content once you interact with the notification. As for Low Power Mode, it primarily defers background activity rather than suppressing pushes; if notifications still arrive on time while Low Power Mode is on, the transport layer is healthy and you should look elsewhere. This distinction prevents a common misdiagnosis where people disable Low Power Mode permanently and see no change.

Per-chat overrides: mute, unmute and exceptions

Per-chat settings win over global settings. That single rule explains most "only this chat is broken" reports. To mute or unmute a conversation, open it, tap the chat name at the top to open the profile, and use the notification toggle there. The duration options typically run from a short interval up to indefinitely; choosing a timed mute is often better than an indefinite one because it expires on its own and does not become a forgotten source of silence six months later.

The exceptions mechanism is the more interesting tool. From Settings → Notifications and Sounds → Exceptions you can add specific chats or users and define how they should behave relative to your global settings. The classic pattern for the channel administrator from Case 1 is: mute the high-volume channel, then add an exception so that direct mentions still produce an alert. The trade-off is documentation overhead — exceptions live in a list that nobody reviews, and after a reorganisation the list can quietly contradict your intent. In a team setting, treat the exception list as configuration that someone owns and reviews occasionally, not as a personal preference.

Common mistakes that keep people stuck

Most of the wasted time in this troubleshooting area comes from a small set of avoidable errors. The first is changing several settings at once. If you alter the in-app category sound, the system channel sound and the battery policy in one pass, you will never know which one mattered, and you will be unable to explain the fix to anyone else. Change one thing, verify, then move on.

The second mistake is testing with the app open. Telegram behaves differently when it is in the foreground, so a successful test proves nothing about the case that actually bothers you. Close the app, lock the screen, wait a few minutes, and only then send the test message.

The third is assuming that reinstalling will help. A reinstall does reset app-level state, but it also wipes local configuration, and on Android it can cause notification channels to be recreated — which sometimes fixes the problem for the wrong reason and leaves you without an explanation. If you reinstall, treat it as a last step after you have ruled out the system layers, and record whether it actually changed anything.

The fourth is disabling battery optimisation for every app on principle. That produces a phone that reports suspicious battery drain and a user who blames Telegram. Apply the change where a delayed notification has a real cost, and leave the rest alone.

The fifth, and the one with the most organisational consequences, is assuming that a delivered notification constitutes a record. It does not, and the next section explains why that matters beyond convenience.

The compliance and retention view: what notifications are not

If your interest in notification reliability comes from an obligation to show that alerts were received, the important message is uncomfortable: a push notification is not an audit artefact. It is an ephemeral presentation event. It can be dismissed, it can be suppressed by a Focus mode, and it may leave no durable trace on the device. For any process where "we notified someone" has to be demonstrable, the notification itself cannot be the evidence.

Notifications versus the message record

The notification and the message follow separate paths and have separate lifetimes. The message is stored according to your chat type and your account settings; the notification is a transient signal about it. Turning off preview, muting a chat, or blocking notifications entirely changes nothing about the underlying message — it remains in the conversation and remains subject to whatever retention rules apply. This is why "I turned off previews to reduce our data footprint" is a misconception worth correcting in any internal documentation: you reduced exposure on the lock screen, not storage.

The corollary is that notification hygiene and retention hygiene are different projects. One is about who sees what on a screen; the other is about how long content exists and where. Confusing them leads teams to believe they have addressed a retention requirement when they have only changed a display setting.

Minimising exposure without losing operational awareness

The practical middle ground, and the one most defensible in a review, is to reduce the information carried by the notification while keeping its timing. Disable message preview so the lock screen shows only that a message exists. Keep the alert sound and the timing intact so the on-call responder still notices. Where a specific high-sensitivity chat exists, consider muting it and handling it through an exception or a separate workflow, rather than leaving its contents on a lock screen that anyone in the room can read.

Least privilege applies here in a way that is easy to implement: give notification rights to the smallest set of people who genuinely need to react, and give visibility of content to the smallest set who need to read it. These are not the same set, and separating them is often the cheapest compliance improvement available.

Retention: device cache, server copy and export

Three different things are often called "the messages": the local cache on the device, the copy held on Telegram's infrastructure for cloud chats, and any export you have deliberately produced. Clearing the cache — reached on Android through Settings → Data and Storage → Storage Usage and on iOS through a comparable Storage Usage section, with labels that vary by version — frees local space and removes local media, but does not delete the server-side copy. If your goal is to reduce what exists, cache clearing is not the tool; auto-delete timers inside a chat, or deletion of the message itself, are closer to what you want.

For situations where you need a durable, reviewable record, Telegram Desktop includes an export function reachable from its settings under an advanced section, which produces a machine-readable copy of the chats your account can access. This is the closest thing to an auditable artefact the ecosystem offers, and it is worth being precise about its limits: it exports what your account can see, at the moment you run it, and it is not a continuous log. Mobile clients do not offer an equivalent full export. Treat exported data with the same care as the original — an export on an unencrypted laptop is a new exposure, not a solved one.

Verification an auditor or colleague can reproduce

A defensible verification is short and repeatable. Close the app completely. Lock the device. Wait long enough that any aggressive background policy would have taken effect — several minutes is usually sufficient. Have a second person, or a second device, send a message to the chat under test. Record whether a notification appeared, whether it produced sound, and how long it took. Then repeat once with the device connected to a different network to rule out a single dead zone. Two consistent runs under the same conditions are worth more than a dozen ad-hoc tests, and the record takes a minute to write.

For muted-chat expectations, add one more run: mute the chat, send again, and confirm that no audible alert occurs but the message is visible on opening. That establishes the baseline against which future "it stopped working" reports can be compared, which is often the real value — not the initial fix, but knowing what normal looked like.

Optimisation tips: reliability without wrecking the battery

The temptation after fixing a notification problem is to apply every permission and exemption available. Resist it. A device with a dozen unrestricted apps is a device that will be charged twice a day, and the person carrying it will eventually reverse your changes in frustration. The optimisation goal is to spend battery only where a delay has a cost.

Start by ranking your chats by consequence rather than by volume. A high-traffic channel that you read once an hour does not need an audible alert; a small group where incidents are reported does. Configure the noisy categories to be silent and the consequential ones to alert, then leave the global settings alone. This produces fewer changes, each of which you can justify.

Second, prefer category-level configuration over per-chat configuration wherever the categories map to your real usage. Category settings survive the addition of new chats; per-chat settings must be repeated for every new conversation, and people forget. Exceptions are the right tool only for the small number of chats that genuinely deviate from their category.

Third, revisit the settings after any device migration. Notification channels on Android and system permissions on iOS do not always transfer cleanly when you move to a new phone, and a restored backup can reproduce an old configuration that no longer matches how you work. A five-minute review after a migration prevents a week of confusing behaviour.

Risks and boundaries: when not to chase the fix

There are situations where continuing to troubleshoot is the wrong decision. On a managed device where settings are greyed out, the change belongs to the administrator, and repeated attempts waste time while creating a policy problem. On a device with a failing battery or an ageing operating system, delayed notifications may be a symptom of the device rather than of Telegram, and no setting will make it reliable.

There is also a boundary around what a notification can be trusted to do. If a process requires guaranteed delivery — an escalation path, a safety alert — a consumer messaging app is the wrong transport, regardless of how well configured it is. Empirical observation: notification reliability improves markedly when the app is exempted from battery restrictions, but it does not become a guarantee. Choosing a transport appropriate to the consequence is a design decision, not a settings decision, and recognising that early saves a great deal of misdirected effort.

Applicable and non-applicable scenarios

Use the checklist below to decide whether the approach in this article fits your situation. It is deliberately blunt about the cases where it does not.

• Applies: personal devices where you control the settings and can restart the phone if needed.
• Applies: small teams where one or two people own the notification configuration and can document changes.
• Applies: troubleshooting a single chat that has gone quiet, or a category that stopped making sound after a version update.
• Applies: reducing lock-screen exposure by disabling previews on shared or semi-public devices.
• Does not apply: devices under MDM where notification policy is set centrally — escalate instead.
• Does not apply: situations requiring guaranteed delivery or a formal acknowledgement trail; use a transport designed for that.
• Does not apply: meeting a data retention obligation — notification settings do not change what is stored.

Read the list as a filter rather than a scorecard: a single "does not apply" is enough to redirect your effort, and the two middle entries are the ones most often overlooked, because a configuration that was correct last year can drift out of alignment with how you actually work.

Best practices checklist for a maintainable setup

If you take nothing else from this article, adopt the following decision rules. They are ordered so that each one reduces the need for the next.

1. Diagnose the symptom before changing anything: nothing at all, silent, late, or one chat only.
2. Check per-chat mute first; it is the cheapest explanation and the most frequently correct one.
3. Configure by category, not by chat, and use exceptions only where a chat genuinely deviates.
4. Grant unrestricted battery only to the app and the categories where delay has a cost.
5. On Android, verify the notification channel sound in system settings rather than trusting the in-app value.
6. On iOS, treat Focus and Scheduled Summary as prime suspects for time-based gaps.
7. Disable message preview on any device that is shared or leaves your control.
8. Change one setting at a time and verify with the app closed and the screen locked.
9. Write down what you changed and what you observed; a repeatable note beats a screenshot.
10. Review exceptions and notification configuration after any device migration or team change.

The sequence matters more than the individual items. Steps one and two eliminate the majority of cases before you open a system settings page at all, while the last two are what keep the setup from decaying quietly in the months that follow — a configuration nobody reviews is only reliable by accident.

Frequently Asked Questions

Why do Telegram notifications only arrive when I open the app?

This pattern usually indicates that the operating system is restricting background activity rather than that Telegram is misconfigured. On Android, check the app's battery setting and any vendor app-freezing feature, and set Telegram to unrestricted. On iOS, confirm Background App Refresh is enabled for Telegram. After changing either, verify by locking the screen for several minutes and having someone send a test message before you touch the phone. If the notification now arrives unprompted, the background restriction was the cause.

Does turning off message preview change what is stored?

No. Disabling preview affects only what is displayed outside the app, such as on the lock screen. The message itself is unaffected and remains subject to the same storage and retention behaviour as before. Preview settings are a disclosure control, not a retention control, and treating them as the latter is a common misconception worth correcting in internal documentation.

Are messages in muted chats still received and stored?

Yes. Muting suppresses the alert, not the message. The conversation continues to update and the unread count typically still increases. If you need to confirm this on your own device, mute a chat, have a message sent to it, and then open the app: the message will be there even though no audible alert occurred. This is why muting is a poor substitute for leaving or archiving a conversation.

Can an administrator fix notifications remotely on a managed device?

It depends on the management profile in use. Some notification and permission settings can be governed centrally, and where that is the case the relevant pages may appear greyed out or revert after a restart. If you observe either behaviour, the correct next step is to raise it with whoever administers the device rather than attempting a workaround, since reinstalling the app under a different profile may breach your organisation's policy.

Does clearing the cache delete messages from Telegram's servers?

No. Clearing the cache through the app's storage settings removes local files from the device and frees space, but the server-side copy is not affected. If your objective is to reduce what exists, use the in-chat auto-delete option or delete the messages themselves. For a durable record of what your account can access, Telegram Desktop includes an export function in its settings; mobile clients do not provide an equivalent full export.

Where to go from here

Fixing Telegram notifications is usually a matter of finding which of five layers is failing and changing exactly one thing there. Start with the symptom rather than the settings page: no notification at all points outward to the system and the push transport, late notifications point to battery and background policy, silent notifications point to sound configuration at the channel or system level, and a single quiet chat points to a mute. That ordering alone resolves the majority of cases without any experimentation.

Once notifications work, spend a few minutes making the setup maintainable. Configure by category, reserve exceptions for genuine deviations, disable previews on devices that are shared or that leave your possession, and write down the one or two settings you changed so that the next person facing the same problem does not start from zero. Treat the notification path as something to be verified rather than assumed, and treat the message record as a separate concern with its own rules. That separation is what keeps a working setup working, and it is also what makes your configuration explainable when someone else asks why it is set up the way it is.

Version expectations and how this guidance ages

Nothing in the paths above is permanent. Menu labels are renamed between releases, notification categories are added or merged, and vendor battery managers are rewritten with new names on a schedule of their own. Empirical observation: the layer model outlasts the labels, which is why this article describes stages of delivery rather than promising that a given word will appear on a given screen.

A workable habit is to re-verify after any major platform update rather than after every app update. If a setting you relied on has moved, the symptom will usually change shape as well — a silent chat that starts making sound, or a category that splits in two — and that change is the cue to look again. Keeping your written note from the verification step makes that five-minute review inexpensive, because you already know what normal looked like before the update arrived.