Key Takeaway
Adalo push notifications only work in a native app published to the App Store and Google Play, never in a web app or the preview. You add a Send Notification action, point it at a target user or a collection of users, and choose whether it fires on a trigger or on a schedule. Push is one of the most reliability-sensitive features you can ship, so plan around delivery limits before you depend on it.
Push notifications are one of the most requested features in Adalo, and also one of the most misunderstood. Builders set one up, test it in the preview, see nothing happen, and assume it is broken. Most of the time it is working exactly as designed. This guide walks through the real setup, the native publish requirement that trips up almost everyone, how to target the right users, the difference between triggered and scheduled sends, and an honest look at where delivery gets shaky.
The one requirement nobody mentions first: native publish
Before you touch a single action, understand this. Adalo push notifications require a native mobile app. They do not work in the web app build, they do not work in the in-browser preview, and they do not work in the shared preview link you send to a client. Push is a feature of iOS and Android, and it only exists once your app is installed from the App Store or Google Play.
That means the testing loop most people expect does not apply. You cannot click around the preview and watch a banner appear. To verify a push notification actually fires, you have to:
- Publish the app natively through Adalo to the App Store and Google Play, or to a test track like TestFlight on iOS and internal testing on Google Play.
- Install that build on a real physical device. Simulators and emulators are unreliable for push.
- Grant notification permission when the app prompts you on first launch.
- Trigger the notification from a real action in the live app.
If you skip the native build, nothing is wrong with your setup. The channel simply does not exist yet. As of 2026 this is still the number one reason people think Adalo push is "not working."
A quick note on permissions
iOS requires the user to explicitly opt in to notifications, and they only get asked once by default. If a user taps "Don't Allow," you cannot re-prompt them from inside the app. They have to go into their device Settings to turn notifications back on. Plan your first-launch experience so you ask for permission at a moment when the value is obvious, not the instant the app opens.
Adding a push notification action
Once you have a native build, the actual setup in the Adalo editor is straightforward. Notifications are added the same way as any other action, attached to a button, a form submit, or another component.
- Select the component that should send the notification, for example a button or a list item.
- Open the Actions panel and click Add Action.
- Choose Notifications, then Send a Notification.
- Pick who receives it, which is the targeting step covered below.
- Write the title and body text. You can mix in dynamic data from your collections, for example the sender's name or an order number.
- Optionally set a Link so tapping the notification opens a specific screen in your app.
That link step is what people mean by "notification actions." A push that just shows text is fine, but a push that deep-links into the relevant screen is what actually drives the behavior you want. If you send "You have a new message," link it straight to the conversation, not the home screen.
Targeting the right users
Targeting is where Adalo push gets genuinely useful, and where most mistakes happen. You are choosing the recipient of the notification, and Adalo gives you a few patterns.
- A single user from a relationship. The most common pattern. If a comment belongs to a post, and the post belongs to a user, you can send the notification to that post's owner. This is how "someone replied to you" works.
- The logged-in user. Useful for confirmations, for example "Your order was received."
- A list or collection of users. You can send to everyone in a filtered list, for example all users who opted into a category. Be careful here, broad sends are where reliability and rate limits start to matter.
The key thing to get right is the data path. Adalo can only notify a user it can reach through a relationship in your data. If your collections are not connected the way you think, the notification quietly goes nowhere. Before you blame push, confirm that the user record you are targeting is actually linked to the action that fires.
Triggered vs scheduled notifications
There are two fundamentally different ways a notification leaves your app, and they solve different problems.
| Type | How it fires | Best for | Watch out for |
|---|---|---|---|
| Triggered | In response to an action a user takes, for example a new message, a like, or an order | Real-time, one-to-one relevance | Depends on the action actually completing. A failed action means no push |
| Scheduled | At a set time or on a recurring basis, often via a database-driven workflow or a scheduled list send | Reminders, daily digests, announcements | Adalo has no built-in "send at 9am tomorrow" field. Scheduling usually needs a workaround |
Triggered notifications are native to Adalo. You attach the Send Notification action to the thing that should cause it, and it fires when that action runs. This is the simplest and most reliable pattern.
Scheduled notifications are harder, because Adalo does not give you a clean "send this at a future time" control inside the standard notification action. The common approaches are:
- Storing a send time in a collection and using a recurring process or external automation to check that collection and trigger sends when the time arrives.
- Connecting an external tool through Adalo's API or a service like Make or Zapier to fire notifications on a schedule.
- Using a third-party push integration, for example a dedicated push service, when you need real scheduling, segmentation, and delivery reporting that the native feature does not provide.
If your whole product depends on timed reminders, treat scheduling as a real engineering decision, not a checkbox.
Be honest about delivery reliability
This is the part most tutorials skip, and it is the part that matters most. Push notifications are never 100 percent reliable on any platform, and that is doubly true on a no-code stack where you do not control the underlying infrastructure.
Here is what actually affects whether a notification arrives:
- The OS decides, not you. Apple and Google both throttle, batch, and sometimes drop notifications based on battery state, Focus modes, Do Not Disturb, and their own heuristics. A "sent" notification is not a "delivered" one.
- Permission state. Users who never opted in, or who later turned notifications off, receive nothing, and you often have no clear signal that they are unreachable.
- Token freshness. Device push tokens expire and rotate. If the stored token is stale, the message goes to a dead address.
- Volume and timing. Large simultaneous sends to a big list can run into rate limits or partial delivery. Background and time-sensitive delivery behaves differently across iOS and Android.
- Limited visibility. The native Adalo flow gives you little in the way of delivery receipts or analytics. When something does not arrive, diagnosing why is hard because you cannot see the layer where it failed.
None of this is unique to Adalo. Every push system has these constraints. The difference is that on a managed native build you have logs, monitoring, and the ability to inspect and retry. On a no-code app, when delivery gets flaky, you are often left guessing, and your users just quietly stop getting the thing you promised them.
Three ways to handle push, compared
Once you know native publish is required and that delivery is best-effort, the real question is who carries the operational weight. There are three common setups, and the right one depends on how much push reliability matters to your business and how much of it you want to own yourself.
| Approach | Scheduling and segmentation | Delivery visibility | Who maintains it | Best for |
|---|---|---|---|---|
| Adalo native push | Triggered only out of the box. Scheduling needs a workaround | Minimal. Little delivery reporting | You, inside the Adalo editor | Low-stakes, in-app event alerts |
| Adalo plus a dedicated push service | Strong. Real scheduling, audiences, and A/B sends | Good. Open and delivery dashboards | You, across two tools you wire together | Marketing sends where reporting matters |
| Done-for-you native build | Whatever the product needs, built and monitored for you | Full. Logs, monitoring, and retries | An operating team, not you | Transactional or time-sensitive push you cannot afford to drop |
There is no single right answer. If push is a nice-to-have, the native feature is fine and free of extra moving parts. If it is core to how your product earns trust, the cost of a missed notification is what should drive the decision, not the cost of the tool.
A practical setup checklist
- Publish a native build to the App Store and Google Play, or test tracks. Push will not work otherwise.
- Test on a real physical device with permission granted.
- Confirm the data relationship between the action and the target user before debugging anything else.
- Add a deep link so the notification opens the relevant screen, not the home screen.
- Use triggered notifications where you can. Treat scheduled sends as a deliberate, separate build.
- Set expectations with stakeholders. Push is best-effort delivery, not guaranteed delivery.
FAQ
Why are my Adalo push notifications not working?
The most common cause is testing in the web app, the preview, or a shared link. Push only works in a native app installed from the App Store or Google Play, on a real device, with notification permission granted. If you are testing anywhere else, there is nothing to fix. The channel does not exist yet. The second most common cause is a broken data relationship, where the action is not actually connected to the user record you think it is targeting.
Do Adalo push notifications work on the web app?
No. Adalo push notifications are a native mobile feature. The web app build does not support them. If web reach matters to you, you would need a separate web push solution outside of Adalo's native notification action.
Can I schedule push notifications in Adalo for a future time?
Not with a simple built-in field. The native action sends when its trigger fires. To schedule a send for a specific future time, you typically store the send time in a collection and use a recurring process or an external automation tool to fire the notification when that time arrives. For real scheduling and segmentation, many teams add a dedicated push service.
How do I make a notification open a specific screen?
In the Send a Notification action, set the Link to the screen you want the user to land on, and pass any data that screen needs, for example the specific record. This is what turns a generic alert into something useful. Without a link, the tap just opens the app's default screen.
Are Adalo push notifications reliable enough for a real business?
For low-stakes, non-time-critical messages, the native feature is usually fine. For anything where a missed or late notification costs you money or trust, such as appointment reminders, time-sensitive offers, or transactional alerts, the lack of delivery visibility and scheduling control becomes a real risk. At that point teams usually either bolt on a dedicated push service or move to a native build they can monitor properly.
The bottom line
Push is the clearest example of why reliability matters in app development. It is a feature that looks simple in a tutorial and gets complicated the moment real users depend on it. The native publish requirement, the targeting logic, the scheduling gaps, and the delivery limits are all manageable, but they take ownership and monitoring to manage well.
If you would rather not own that complexity, that is the model we run at Rehost. We are a small Los Angeles team that designs, builds, hosts, monitors, and operates custom apps for you. Push notifications are set up, monitored, and fixed by us, and when you want to change a message or add a notification flow, you send us a plain message and we ship it. You never log into a dashboard. You also own the app, the App Store and Google Play developer accounts, the domain, the code, and your customer data, all portable if you ever leave. Business plans start at around $950 a month as of 2026, billed by monthly active users, with no setup fee and month to month terms. You can see the full breakdown on our pricing page, estimate your own number with the app calculator, or just tell us what you want to build.