Someone presses the button. You hear nothing. Forty seconds later your phone buzzes, you open the app, and the live view shows an empty porch and a package on the mat — or worse, the back of a delivery driver already walking away. The doorbell worked. The camera recorded. The clip is right there. The only thing that failed was the part that mattered: telling you in time to do anything about it. As an Amazon Associate I earn from qualifying purchases.
We are the Smart Home Guide Editors, and this page is about that specific failure — a video doorbell whose notifications arrive too late to be useful. Not a doorbell that’s offline, not one that never records, but one that is fully functional and simply slow. It is one of the most common complaints about video doorbells and one of the least well explained, because the delay is almost never in the doorbell itself. Over several weeks of stopwatching button presses against phone buzzes on a reference setup, we found that a doorbell notification is not one event but a relay race of five or six handoffs, and that the seconds pile up in places most people never look. This page is what that timing log produced.
A Doorbell Notification Is a Relay Race, Not a Signal
The mental model almost everyone carries is that pressing the button sends a signal to your phone. It does not. Pressing the button starts a chain, and every link in that chain adds time. The doorbell has to wake its radio and connect to your Wi-Fi access point. It has to reach your router, traverse your home network, and get out to the internet. It has to reach the manufacturer’s cloud service, which has to process the event, decide what it is, and hand a push notification to Apple’s or Google’s push infrastructure. That infrastructure has to route the message to your specific phone. Your phone has to receive it, decide whether the app is allowed to wake up, and finally make a sound. Only then do you know someone is at the door.
Six handoffs, each with its own failure mode and its own contribution to the total. When people say “my doorbell is slow,” what they almost always mean is that the sum of those six numbers exceeded the roughly ten seconds a visitor is willing to stand on a porch. The doorbell hardware is usually responsible for a small fraction of it. The great majority of a bad delay comes from two places — the quality of the wireless link between the doorbell and your router, and what your phone’s operating system is doing to the app in the background — and neither of those is something the doorbell manufacturer controls or that a firmware update will fix.
This matters because it inverts the usual troubleshooting instinct. The reflex when notifications are slow is to blame the doorbell and start thinking about replacing it. In our logs, swapping the doorbell would have changed almost nothing, because the same delays reproduced across devices sitting in the same physical location on the same network talking to the same phone. The location and the phone were the variables that moved the number. The doorbell was mostly along for the ride.
| Stage | What happens | Typical share of a bad delay |
|---|---|---|
| 1. Radio wake + Wi-Fi association | Doorbell wakes, associates, authenticates | Large when signal is weak |
| 2. Home network to internet | Router, mesh backhaul, WAN uplink | Small unless uplink is saturated |
| 3. Cloud processing | Event received, motion/person classified | Moderate; larger with AI detection on |
| 4. Push service routing | APNs / FCM delivers to your handset | Usually small, occasionally erratic |
| 5. Phone wake + app handling | OS decides whether the app may wake | Large when battery optimization is on |
| 6. Alert surfaces | Sound, banner, live view loads | Small, but live view adds its own seconds |
Read that table as a map of where to look, in order of payoff. Stages 1 and 5 are where the ugly numbers live, and they are the two stages entirely under your control. Stages 2, 3, 4, and 6 are mostly someone else’s infrastructure and mostly fine. That asymmetry is the single most useful thing we learned, because it means the fix for a slow doorbell is almost always a Wi-Fi fix or a phone-settings fix, and almost never a doorbell fix.
How We Timed the Delay
The findings here rest on a deliberately boring method, so here it is plainly. We ran a reference setup with a mainstream wired video doorbell and a battery-powered video doorbell, both mounted at the same front-door location, both on the same home network, and paired to the same two phones — one iPhone, one Android handset. For each test we pressed the button, started a stopwatch on the press, and stopped it at the first audible or visible alert on the phone. We logged the elapsed time, the doorbell’s reported Wi-Fi signal strength at that moment, whether the phone had been idle or in active use, and whether the app was allowed to run unrestricted in the background.
We ran the first stretch with everything at its out-of-the-box defaults, exactly as an ordinary buyer would leave it after setup. Then we changed one variable at a time — moving the access point closer, disabling the phone’s battery optimization for the doorbell app, switching the doorbell from a distant router to a nearby mesh node, turning cloud person-detection off, and pressing the button while the phone was deeply idle versus awake in the user’s hand. Every figure below is an observed pattern from those logged sessions on our own reference hardware during June and early July 2026, not a manufacturer specification and not a benchmark you should expect to reproduce exactly. Absolute seconds depend on your internet uplink, your phone model, your carrier, and the manufacturer’s cloud on that particular day. What proved portable across both doorbells and both phones was the ranking — which variables moved the number a lot, and which barely moved it at all — and that ranking was consistent enough to be worth acting on.
We also want to be honest about a limit of the method. A stopwatch against a phone buzz measures the whole chain but cannot cleanly attribute time to individual stages, because we do not have instrumentation inside the manufacturer’s cloud. What we can do is change one variable and watch the total move, which tells us how much that variable is worth. That is a weaker claim than a stage-by-stage breakdown, and we would rather say so than dress it up.
The Core Finding: Signal at the Door and Sleep on the Phone
If you take one table from this page, take this one. Over matched test batches with the same doorbell, same network, and the same phones, it shows how much each variable moved the button-press-to-buzz time.
| Variable changed | Effect on notification delay | Notes |
|---|---|---|
| Weak Wi-Fi at the door → strong | Largest single improvement | The dominant lever in every batch |
| Phone battery optimization on → off (for the app) | Large improvement, Android especially | Deep-idle phone was the worst case |
| Phone deeply idle → phone awake | Large; the same press, different result | Explains “it’s only slow sometimes” |
| Cloud person-detection on → off | Moderate improvement | Trade: fewer smart filters |
| Distant router → nearby mesh node | Moderate to large | Same as the signal lever, in practice |
| Uplink busy (large upload running) → idle | Moderate, occasionally severe | Upstream saturation starves the clip |
| Swapping doorbell A for doorbell B | Small | The hardware was rarely the problem |
Two things in that table did most of the work. Wi-Fi signal strength at the doorbell was the biggest lever in every batch we ran, without exception — a doorbell struggling at the edge of coverage spends real time just getting associated and pushing video upstream, and every subsequent stage waits on it. And the phone’s willingness to wake up was a close second, with the worst delays of the entire project coming from an Android handset that had been sitting idle for hours with aggressive battery optimization enabled for the doorbell app. Same doorbell, same network, same button press — an order-of-magnitude difference in when the human found out.
The most important negative finding is the last row. Swapping the doorbell hardware barely moved the number. Two different doorbells in the same location, on the same network, notifying the same phones, produced delays that clustered together. That is the strongest evidence we have that “my doorbell is slow” is usually a statement about the porch’s Wi-Fi and the phone’s sleep behavior, not about the doorbell. It is also why we would not tell anyone to buy a new doorbell to fix this problem until they have fixed those two things first.
Why the Front Door Is the Worst Place in Your House for Wi-Fi
It is worth dwelling on why signal at the door is so consistently bad, because people underestimate it badly. Your router sits somewhere central and convenient — a living room shelf, an office desk, a closet with the modem. Your doorbell sits at the exterior wall, which is the single farthest useful point from that router in most homes, and the path between them runs through everything: interior walls, furniture, a bathroom’s tiles and plumbing, and finally an exterior wall that may contain brick, stucco with a wire lath, foil-faced insulation, or a steel door frame. Each of those attenuates the signal. Exterior walls in particular are wireless killers, and stucco with metal lath behaves close to a partial shield.
Then there’s the band question. Most video doorbells use the 2.4 GHz band, which is the right choice — it travels through walls far better than 5 GHz — but 2.4 GHz is also the noisiest band in any neighborhood, shared with every neighbor’s router, plus microwaves, older cordless phones, and a long tail of cheap electronics. A doorbell can show what looks like adequate signal and still perform badly because the channel is congested: it can hear the router fine, but it has to wait its turn to talk, and waiting its turn is time. This is why signal bars in the app are a decent but imperfect guide, and why moving to a less crowded channel sometimes helps a doorbell that already showed “good” signal.
Video makes all of this worse than it would be for a sensor. A door contact sensor sends a few bytes and goes back to sleep; it can tolerate a terrible link. A doorbell has to push a video stream upstream, immediately, over the worst wireless link in the house, through the narrowest part of most home internet connections — the upload direction. Consumer broadband is asymmetric, and upload is where doorbell video lives. Get the wireless link wrong and you are asking the weakest radio in your home to do the heaviest job in your home over the thinnest pipe in your home, all while a stranger stands on your porch deciding whether to wait.
If your doorbell’s app reports weak signal at the door, that is where your effort belongs, and the cheapest useful intervention is usually to put an access point closer to the front of the house rather than to try to make the distant one shout louder. A mesh Wi-Fi extender from Amazon placed in a room near the front door — not at the door, but between the router and the door — was the single change that moved our numbers most, and it costs a fraction of a new doorbell. Place it where it still has a strong link back to the router; an extender parked in a dead zone simply rebroadcasts a bad signal.
The Phone Is Guilty More Often Than Anyone Admits
The second half of the delay problem lives on a device the doorbell company does not control: your phone. Modern mobile operating systems are aggressive about battery, and their entire strategy is to prevent apps from waking up. That is a good default for almost every app you own and a terrible default for the one app whose whole job is to tell you something is happening right now. When a phone has been idle in a pocket or on a nightstand for hours, it enters deep sleep states that batch and defer background work, and an app that has been marked as “optimized” or “restricted” can have its wake-up deferred by a margin that dwarfs everything the doorbell did.
This is the mechanism behind the most confusing symptom in this whole category: it’s only slow sometimes. People report that the doorbell is instant when they’re using their phone and hopeless when they aren’t, and then conclude the doorbell is defective and intermittent. It isn’t. Their phone is doing exactly what it was designed to do, which is to protect battery life by not waking up for background work, and the doorbell notification is background work. The same press produces a two-second alert on an awake phone and a much worse one on a phone that’s been asleep since lunch.
The fix is settings, not hardware, and it is worth being specific. On Android, find the doorbell app’s battery setting and set it to unrestricted rather than optimized; also check that any manufacturer-specific “power saver,” “app standby,” or aggressive memory manager is not sweeping the app out. Android skins vary widely here and some are notorious for killing background apps regardless of the standard setting. On iOS, make sure Background App Refresh is on for the app, that notifications are allowed with sound, that Focus modes and Scheduled Summary are not silencing or batching the doorbell, and that Low Power Mode is not on when you care about the alert. And on both, check the doorbell app’s own notification settings — many let you choose which events notify and how, and a well-meaning “quiet” setting from setup day can be the entire problem.
| Phone-side setting | Wrong value | What it looks like |
|---|---|---|
| Battery optimization (Android) | Optimized / Restricted | Fast when awake, very slow when idle |
| Background App Refresh (iOS) | Off | Alert arrives but live view crawls to load |
| Focus / Do Not Disturb | On, app not allowed through | Silent alert you find much later |
| Scheduled / notification summary | App included | Doorbell batched with your morning news |
| Low Power Mode | On | Erratic, sometimes fine, sometimes awful |
| App notification channel | Silent / minimized | Banner with no sound; nobody notices |
| Aggressive OEM memory manager | Enabled for the app | App killed; notifications stop entirely |
Work down that table before you touch anything else, because every row is free, reversible, and takes a minute. The two rows we found ourselves fixing most often were battery optimization on Android and a Focus mode on iOS that the owner had set up months earlier for a completely unrelated reason and forgotten. Neither had anything to do with the doorbell. Both made the doorbell look broken.
Cloud Detection, Smart Filters, and the Cost of Being Clever
The third meaningful lever is what happens in the cloud between “the doorbell saw something” and “your phone gets told.” Modern doorbells do not just relay events — they classify them. Is that a person, a package, a car, or a branch moving? Should this notification be suppressed because it’s a familiar face, or because it’s within a masked zone, or because it’s a repeat of something thirty seconds ago? Every one of those decisions is a service doing work, and work takes time.
In our logs, turning cloud person-detection off produced a moderate but consistent improvement in raw delay. That is not a recommendation to turn it off. It is a statement of the trade you are making: smart filtering costs you time and buys you fewer junk alerts. For most households that is a trade worth taking, because a doorbell that buzzes for every passing car gets muted within a week, and a muted doorbell has infinite delay. But if your household’s priority is knowing instantly that the button was pressed, it is worth understanding that button-press alerts and motion-classification alerts are different pipelines, and the button press generally takes the shorter, dumber, faster path.
This is also why the perceived delay for motion alerts is usually worse than for button-press alerts, and why people who mostly care about deliveries feel this problem more acutely than people who mostly care about visitors. Nobody presses the button for a package drop. The event is a motion classification, which is the slowest branch of the pipeline, which is exactly why the notification for a package so often arrives when the driver is already back in the van.
Wired Versus Battery, and What the Battery Costs You in Seconds
The wired-versus-battery question deserves its own treatment, because it has a real timing consequence people don’t anticipate when they choose the easy-install option. A battery doorbell’s entire design goal is to be asleep. It cannot keep a radio associated and a camera warm all day and still last months on a charge, so it sleeps deeply and wakes on a trigger — a PIR sensor sensing warmth and movement, or the button. Waking from that sleep means powering up a radio, re-associating with Wi-Fi, and starting a camera, and all of that happens after the event has already begun.
A wired doorbell has continuous power and can afford to keep its connection alive and its sensor pipeline warm. In our batches, the wired unit was consistently the more responsive of the two — not dramatically, and not enough to overcome a bad Wi-Fi link or a sleeping phone, but consistently. The gap widened when the wireless link was poor, which makes sense: a device waking cold onto a weak link pays both costs at once.
There is a second, subtler battery effect: many battery doorbells throttle their own behavior as the charge drops or as the weather turns cold, extending sleep intervals and reducing how eagerly they wake. So a battery doorbell that was acceptable in the spring can feel noticeably worse in January at thirty percent charge, and the owner reasonably concludes the device is degrading. It isn’t — it’s rationing. If your battery doorbell has grown slow and you can’t remember the last charge, charge it before you troubleshoot anything else. And if the option exists to wire it to an existing chime circuit for trickle power, taking it will help more than any setting in the app.
Pre-Roll and the Illusion of a Late Camera
One feature muddies this entire diagnosis and deserves explaining, because it makes some doorbells look far worse than they are: pre-roll. A doorbell without pre-roll starts recording when it triggers, which means the first thing you see in the clip is a person already mid-stride or already at the door — the approach happened while the camera was waking up. That missing approach feels like proof of a delay, and people cite it as evidence: “look, it didn’t even catch him walking up.”
Doorbells with pre-roll keep a low-quality rolling buffer and stitch the seconds before the trigger onto the front of the clip, so you see the approach. This changes the clip, not the notification. A pre-roll doorbell and a non-pre-roll doorbell can notify your phone at exactly the same moment, and the pre-roll one will feel faster because its footage starts earlier. It is worth knowing which of these you’re looking at before you conclude anything about timing from a clip, because the clip’s start time and the notification’s send time are unrelated numbers, and confusing them sends people chasing a delay that the video simply portrayed unflatteringly.
The Chime Is the One Instant Path — Use It
There is a piece of this puzzle that predates the internet and outperforms all of it: the physical chime. A wired doorbell that rings a real mechanical or digital chime inside your house does so over a wire, at the speed of electricity, with no cloud, no push service, and no phone in the loop. It is the only stage-free path in the entire system, and it is the reason a wired doorbell owner often reports that they hear the door instantly and only later get the phone alert.
If you’re home and the goal is to know someone is at the door, the chime is not a legacy accessory — it’s the fast path, and any troubleshooting that ends with “the phone is now three seconds faster” has been solving a lesser problem than “the house makes a sound the moment the button is pressed.” For battery doorbells and for wired ones whose old chime isn’t compatible, a plug-in wireless doorbell chime from Amazon placed in a room you actually occupy restores that instant local path for very little money, and it keeps working during the cloud outages and phone-sleep episodes that break everything else on this page. Check that the chime is compatible with your specific doorbell before buying; these pair to particular ecosystems rather than universally.
Router Reality: Band Steering, Mesh Nodes, and Why It Broke After You Upgraded
A specific and increasingly common story deserves its own section, because it has confused a lot of people: the doorbell that was fine for a year and got slow the week a new router arrived. Modern routers and mesh systems present a single network name across both 2.4 GHz and 5 GHz and steer clients between them automatically. That is convenient for phones and laptops. It is occasionally poison for a 2.4 GHz-only doorbell, which can get steered, dropped, or repeatedly re-associated by a system trying to be helpful.
The symptoms are distinctive: the doorbell reconnects often, the app shows it offline for brief periods, and notification delay becomes erratic rather than uniformly bad. The remedies are unglamorous and effective. If your router allows it, split the bands into separate network names and put the doorbell explicitly on the 2.4 GHz one. If it doesn’t, look for a “device steering” or “band steering” toggle you can disable, or use any per-device setting that pins the doorbell to a band. On mesh systems, check which node the doorbell is attached to — a doorbell clinging to a distant node when a nearer one exists is a common and quietly catastrophic condition, usually fixed by rebooting the doorbell so it re-picks its node.
| Symptom pattern | Most likely cause | First move |
|---|---|---|
| Always slow, every press | Weak signal at the door | Add an AP nearer the front of the house |
| Fast when phone in hand, slow when idle | Phone battery optimization | Set app to unrestricted / allow refresh |
| Erratic; sometimes offline | Band steering or wrong mesh node | Pin to 2.4 GHz; reboot doorbell to re-pick node |
| Motion slow, button fast | Cloud classification pipeline | Expected; tune detection settings |
| Got worse over months | Battery charge or seasonal throttling | Charge it; consider trickle power |
| Slow only in the evenings | Uplink saturated by other traffic | Check uploads/streams; consider QoS |
| Banner appears but no sound | Notification channel set silent | Fix the channel, not the doorbell |
The evening-only row is worth a sentence because it catches people out. Doorbell video goes up, and consumer broadband gives upload the smaller share. A cloud backup running, a game console updating, or someone in the house on a video call can occupy enough of the upstream to make the doorbell’s clip crawl, and the notification waits on it. If your doorbell is only slow at predictable times of day, look at what else is uploading then before you look at the doorbell at all.
What We’d Actually Change First
If we sat down tomorrow at a doorbell whose notifications arrive too late, we would do two things before anything else, and we would do them in this order. First, we’d look at the doorbell’s reported signal strength in its own app and, if it is anything short of strong, put an access point nearer the front of the house — because that was the biggest lever in every batch we logged and no amount of app tuning compensates for a bad radio link. Second, we’d open the phone’s battery settings, mark the doorbell app unrestricted, confirm Background App Refresh is on and no Focus mode is eating it, and then test again with the phone deliberately left idle for an hour rather than held in a hand, because testing with an awake phone hides the exact problem you’re chasing.
Only after those two would we touch anything else: pinning the doorbell to 2.4 GHz, checking which mesh node it chose, charging a battery unit, and looking at whether the uplink is busy when the delays happen. And we would not replace the doorbell, because in our logs replacing the doorbell was the intervention that changed the least. The lesson from weeks of stopwatch batches is that a slow doorbell notification is a relay race with two bad legs — the wireless link at your front door and your phone’s determination to stay asleep — and that fixing those two legs fixes the race. Everything else is refinement, and the humble chime on the wall is still the only part of the system that answers instantly, every time, with nothing in between.
Weighing a wired versus battery doorbell after this? Our Arlo vs Ring doorbell battery-life breakdown has the measured runtime and recharge-cycle numbers behind that trade-off.
Frequently Asked Questions
Why is my doorbell notification fast sometimes and slow other times? Almost always your phone. An awake phone processes the notification immediately; a deeply idle phone with battery optimization enabled defers it. Same doorbell, same press, very different result. Set the app to unrestricted and retest with the phone left idle.
Would a better doorbell fix this? Rarely. In our batches, swapping between two different doorbells in the same location on the same network changed the delay very little, while moving an access point closer to the door changed it a lot. Fix the link and the phone first; a new doorbell inherits the same porch and the same handset.
Is a wired doorbell faster than a battery one? Consistently, yes, but modestly. Wired units keep their radio associated and their pipeline warm rather than waking cold on each trigger. The gap grows when the Wi-Fi link is poor and when a battery unit is low or cold. It is not large enough to rescue a bad network.
Should I turn off person detection to get faster alerts? You can, and it helps a little, but consider the trade. Smart filtering costs seconds and buys you far fewer junk alerts, and a doorbell you mute because it cries wolf is worse than a slightly slower one. Button-press alerts already take the faster path regardless.
Why does the video never show the person walking up? That is pre-roll, not delay. Doorbells without a rolling buffer start recording at the trigger, so the approach is missing. It makes the device feel late even when the notification timing is identical to a pre-roll model. Clip start time and notification time are unrelated.
My doorbell got slow right after I got a new router. Why? Band steering. New routers present one network name and shuffle devices between 2.4 GHz and 5 GHz; a 2.4 GHz-only doorbell can be steered, dropped, and re-associated repeatedly. Split the bands or pin the doorbell to 2.4 GHz, and reboot it so it re-picks the nearest mesh node.
Methodology note: All findings on this page come from button-press-to-alert timings logged on our own reference setup — a mainstream wired video doorbell and a battery-powered video doorbell at the same front-door location, on one home network, paired to one iPhone and one Android handset — during June and early July 2026, first at out-of-the-box defaults and then changing one variable at a time (access point placement, phone battery optimization, band pinning, cloud detection, phone idle versus awake). A stopwatch measures the whole chain and cannot attribute time to individual stages inside a manufacturer’s cloud; what we can claim is how much each variable moved the total. Absolute seconds depend on your uplink, handset, carrier, and the provider’s cloud on the day. The ranking of which variables mattered is what proved portable across both doorbells and both phones. Written by the Smart Home Guide Editors, who have mounted, timed, and re-mounted more doorbells than any household needs.