Start here
No iPhone needed, and no account either
Notify! started as an iOS app, but a phone is not how you get in. Open web.getnotifyapp.com, allow notifications once, and that browser becomes a full Notify! device with its own webhook URL. Android, Windows, Linux, ChromeOS and macOS all work this way. There is nothing to sign up for: no email address, no password, no subscription. A device is identified by an ID and a token the page hands you, not by a login.
Turn this browser into a Notify! device
One page, one permission prompt, and you have a URL that anything can curl to put a notification on this screen.
- Your own webhook URL, with a copy button and a test button that sends a real push.
- Works with cron, CI pipelines, Zapier, Make, Homebridge, Uptime Kuma, or plain curl.
- Joins Device Groups made in the iOS app, so one send reaches a phone, a Mac and a browser together.
- Keeps a history of what arrived, on the same page.
- No account, because Notify! does not have accounts.
The details
Is there really no account? expand_more
Really. No sign-up, no email address, no password, no subscription, on any platform. A device registers itself and gets a Device ID and a Device Token, and those two strings are the whole of your identity. Keep the token private, because anyone holding it can send you notifications. There is nothing else to protect and nothing to be locked out of.
Which browsers and machines work? expand_more
Chrome and Edge on Windows, macOS, Linux, ChromeOS and Android are the tested path. Firefox, and Safari 16 and later on the Mac, generally work as well. On iPhone and iPad, install the free app instead; it does more there. The web app is a website, so there is nothing to install, though Chrome on Android will offer to add it to your home screen if you want it to sit alongside your other apps.
How do I set it up? expand_more
Open web.getnotifyapp.com, click "Enable notifications", and allow the permission prompt. That is the whole setup. The page then shows your Device ID, your token and your webhook URL, with copy buttons and a button that sends you a real test push. For richer payloads (titles, icons, images) compose them in the Builder or read the API docs.
My browser notifications stopped arriving. expand_more
Open the web app again. Browsers quietly retire push subscriptions (cleared site data, long inactivity, a permission change), and the app re-registers itself every time it opens. If you cleared the site's data entirely, the page comes back as a brand-new device with a new webhook URL, so re-paste that URL anywhere you had used the old one.
Can the browser join my Device Groups? expand_more
Yes. In the web app's Groups tab, paste the 15-character group token from the Notify! app (Devices tab, pick your group, Share). The browser then receives everything sent to the group, alongside your iPhones and Macs. Groups themselves are still created in the iOS app.
What is genuinely iPhone and iPad only? expand_more
Live Activities: the tiles that sit on the iOS Lock Screen and update in place. They are an Apple feature and no browser can show them. Watching a website for changes on the device itself is also an app feature, though a ChangeDetection.io server can do the watching and push the result to any device, browsers included. Following a feed is the third: feeds are read by the app on the device, and connecting a server does not move that off the device, so a feed needs the app. Everything else (webhooks, groups, history, sounds, icons, images) works in the browser, within what your browser and operating system support.
TRMNL e-ink dashboards
The Notify! plugin for TRMNL
TRMNL is a small e-ink panel that shows dashboards on a wall. The Notify! plugin puts one Notify! device's recent notification history on it: the time, who sent it, the title, the message, and anything that failed to deliver. It only reads. It cannot send you a notification, and it cannot change anything in Notify!.
No Apple ID. No iPhone. No account of any kind.
This is the question we get asked most, so here it is before anything else: you do not need an Apple ID, an iPhone, or a Notify! account to run this plugin. Notify! has no accounts at all. There is nothing to sign up for, nothing to verify, and no email address to hand over.
All the plugin needs is a Device ID and Device Token, which is one pair of short strings. You can get that pair in either of two ways, and the plugin cannot tell them apart:
- Use the device you already have. If Notify! is on an iPhone or iPad, its Device ID and Token are already waiting in the app.
- Or make a new one in a browser, on any platform. Open web.getnotifyapp.com in Chrome, Edge, Firefox or Safari 16+, allow notifications once, and that browser becomes a Notify! device with its own Device ID and Token. Android, Windows, Linux, ChromeOS and macOS all work. No Apple hardware is involved anywhere in that sentence.
What you need
- A TRMNL device and a TRMNL account. Both are TRMNL's, not ours, and they are the only account in this whole arrangement.
- One Notify! device, identified by its Device ID and Device Token, from either source above.
- Device credentials, not group credentials. The plugin shows one device's history, so it turns a group ID and token away at the settings page rather than saving cleanly and then failing on every refresh.
Setting it up
- Find your Device ID and Token. In the iOS app: Settings, then Device. In the web app: the Device tab, where both sit above your webhook URL with copy buttons.
- Add the Notify! plugin in TRMNL and press "Connect with Notify!". That opens a settings page we host at notifytrmnl.pingie.com, which is the only page that ever asks for these credentials.
- Paste the Device ID and Token, then choose what the screen shows: how many notifications (1 to 50, twelve by default), everything or only failed deliveries, whether to print where each notification came from, and whether to show sender icons.
- Save. The pair is checked against the Notify! server there and then, so a wrong token is a message in front of you rather than a blank panel at two in the morning. You land back in TRMNL and the screen redraws on its next refresh.
What data the plugin sees, and where it goes
Are my notifications stored? expand_more
No. Nothing from your notification history is written to disk here. Every few minutes TRMNL asks the plugin for a screen; the plugin fetches that device's most recent notifications from the Notify! server at that moment, lays them out, and hands the result straight back. Fetched rows are held in memory for 60 seconds so a burst of refreshes does not hammer the server, then dropped. Message bodies are cut to 200 characters before they ever leave the Notify! server, so the plugin never receives the full text of a long message.
Who else sees the notification text? expand_more
TRMNL does, and that is unavoidable rather than incidental: TRMNL is what turns the layout into an image and sends it to the panel, so titles and message previews pass through TRMNL's servers on the way to your wall, under their policies rather than ours. The plain version: a wall panel is a public screen. If a device receives things you would not want read across the room, or handled by a third party, that is not the device to point this at. Point it at one whose alerts you are happy to display.
What about sender icons? expand_more
A notification can carry an icon URL for whoever sent it, and roughly one in fifty do. With icons switched on, the screen includes that image and TRMNL's renderer fetches it from whichever host it lives on, which tells that host roughly when your screen refreshed. Only https URLs are used and anything unparseable is dropped. If you would rather not make those requests, or a detailed color logo renders as mud on e-ink, turn icons off in plugin settings.
What happens when I uninstall? expand_more
TRMNL tells the plugin, and the row is deleted, encrypted Device Token included. Nothing is kept for later. Reinstalling asks for the Device ID and Token again, on purpose: a fresh install has not proved it owns the device the old one was pointed at.
Anything else worth knowing? expand_more
The plugin talks to exactly two places: the Notify! server and TRMNL. No analytics, no trackers, nothing sold and nothing shared. Its logs record Device IDs and TRMNL user ids so a support question can be answered, and never record a token. Your Device Token is the one credential that matters here, which is why it is encrypted at rest and why that settings page is the only thing that ever asks for it.
Limits worth knowing before you install
- One Notify! device per TRMNL account. A second screen shows the same device, not a different one.
- Device history only. Group history is not read.
- It displays, it does not send. Zapier, Make, Homebridge and Uptime Kuma are the sending direction, and they live on the automations page.
- It does not monitor websites. That is the iOS app, or a ChangeDetection.io server.
- On-device alerts never reach it. Feed updates and on-device site checks are made on the iPhone or iPad itself and never pass through the Notify! server, so there is no row for the panel to read.
- Message previews stop at 200 characters. The panel is a glance, not an archive.
If the screen is not showing what you expect
- "Almost there" or "Setup needed" means the plugin has no Device ID and Token yet. Open the plugin's settings in TRMNL and enter them.
- "Notify! unavailable" arrives with a sentence naming the reason. A rejected Device ID and Token is the common one, and pasting both again fixes it.
- The panel prints the reason instead of going blank on purpose. A blank screen tells you nothing from across the room.
- Straight after saving, give it one refresh cycle. TRMNL owns the schedule, not the plugin.
- Still stuck? The form at the bottom of this page reaches a person.
Common questions
Why some websites cannot be monitored
Notify! can monitor most websites, but some sites have special restrictions that prevent automated monitoring. Here is what to look out for, and what you can do about each one.
Security protection (Cloudflare, bot detection) expand_more
Many popular websites use services like Cloudflare to protect against bots and automated access. These systems can detect and block monitoring attempts, showing CAPTCHAs or error pages instead of the actual content.
Login requirements expand_more
Content behind login pages (like your email, banking sites, or social media feeds) cannot be monitored without providing credentials. Notify! does not store passwords for security reasons.
JavaScript-heavy sites expand_more
Modern websites often load content dynamically using JavaScript. Sites like Twitter, Instagram, or single-page applications may appear blank because the content loads after the initial page request. If the site publishes a feed, this one goes away entirely: follow the feed instead and Notify! never loads the page at all.
Rate limiting expand_more
Websites may temporarily block your device if they detect too many requests. This is especially common with e-commerce sites during sales or high-traffic periods.
Geographic restrictions expand_more
Some content is only available in specific countries or regions. If a site works in your browser but not in Notify!, it might be using your location to restrict access.
Temporary server issues expand_more
Sometimes the problem is not on your end. Websites undergo maintenance, experience outages, or have temporary technical issues that prevent monitoring.
Does the site publish a feed? expand_more
Worth checking before you go any further, because it is the one fix that costs nothing. Of the problems above, following a feed removes exactly one: the JavaScript rendering, since the feed is read instead of the page. It does nothing for bot protection, login requirements, geographic restrictions, or a site that is simply down, because it is still the same request from the same device. When it does apply, though, it needs no server and no setup. How feeds work in Notify!
The easier fix
Before you reach for a server, check for a feed
Most blogs, news sites and release pages already publish a feed: a plain, machine-readable list of what they have posted. Notify! reads that directly, so a new post arrives as one notification naming the source and the title, instead of a diff of whatever else moved on the page. Feeds live in their own tab in the app, separate from Sites.
What following a feed gets you
Notify! reads RSS 2.0, Atom and JSON Feed 1.1, so you do not need to know which one a site uses.
- No page to scrape. A site that builds its content with JavaScript stops being a problem, because the feed is read instead of the page.
- Only genuinely new items reach you. Notify! remembers each post by the id the feed gives it, so a corrected or republished post stays quiet.
- The alert names the source and the post title. History keeps the author, the date, the link, and whatever article text the feed provides.
- Nothing to install and nothing to run. No server, no account, no configuration.
Adding one
- Open the Feeds tab and tap to add.
- Paste the plain site address and tap Discover Feeds. Notify! fetches the page and reads the feed links the site declares in its own HTML.
- Pick one from the results. If a site publishes several they are listed, and tapping one adds it and closes the sheet. Adding a second feed from the same site means running discovery again.
- Or skip discovery: turn on Add Feed URL Directly and paste the feed address itself. That is the fallback whenever discovery comes back empty.
Worth knowing before you rely on it
Why is a feed I just added completely silent? expand_more
On purpose. The first check records where things stand at the moment you added the feed and sends nothing, so adding a feed does not hand you the last twenty posts. You will hear about posts published after you added it. One consequence worth knowing: a post that turns up later but is back-dated to before you added the feed will not notify you.
It says "No feeds found on this website" expand_more
Discovery reads the feed links a site declares in its own HTML. If a site publishes a perfectly good feed but never links to it, or builds that link with JavaScript, discovery will not find it. Notify! does not go guessing at addresses on your behalf. If you can find the feed yourself, often by trying /feed, /rss.xml or /index.xml in a browser, turn on Add Feed URL Directly and paste it in. A different message, "URL is not a valid feed", means the address you pasted is a page rather than a feed.
How often does it check? expand_more
As often as every 15 minutes. That comes from the single Check Interval in Settings, which every feed shares, and unlike a site watch an individual feed cannot be given its own schedule. Where the checking happens depends on the mode: in Local Mode feeds refresh in the background on the same pass as your site checks, and in Server Mode your ChangeDetection.io server never sees a feed, so feeds refresh while the app is open or when you pull to refresh. Either way iOS decides when background time is granted, so the interval is a target rather than a promise. In Notifications Only mode the Feeds tab does not appear at all. If a site publishes a burst, you get the 5 newest posts from that check rather than one notification per article.
Which problems does a feed not solve? expand_more
A feed removes the JavaScript problem above, because the feed is read instead of the page being rendered. It does not get you past Cloudflare bot protection, a login requirement, or a geographic restriction. It is the same request from the same device to the same site. Feeds that need a login are not supported at all, because Notify! has nowhere to put a username and password. A feed address that already has a personal key in it does work, since Notify! fetches the address exactly as you paste it, though it is also stored on the device exactly as typed.
Is this iPhone and iPad only? expand_more
Yes. Feeds are read by the app on the device, so a browser registered as a Notify! device cannot follow one, and neither can Notify Listener for Mac. Feed alerts are also made and delivered on the device itself and never pass through the Notify! server, which means they do not reach a Device Group, do not appear in the notification history the API returns, do not show on a TRMNL panel, and do not sync to your other devices. A feed added on your iPhone stays on that iPhone. The one thing that does leave the device is the site's domain, sent to our favicon service so the alert can show the site's icon. The feed address itself and everything in it stay where they are.
The feed shows new posts but never notifies me expand_more
Usually the feed does not put a publish date on its items. Notify! works out what is new from that date, and from the unique id a publisher gives each item where one exists. An item with no date at all cannot be placed against the moment you added the feed, so it gets skipped. That is on the publisher's side and there is nothing to change in the app. Check the app too: a failed check puts a red Error pill on the feed in the list, and the reason itself is on that feed's own screen. Nothing alerts you when a feed quietly stops, so a feed you have not heard from in a while is worth opening.
The fix for tricky sites
The solution: Notify! Server Mode
What a server adds
Connect Notify! to a ChangeDetection.io server for powerful, reliable monitoring that bypasses most restrictions.
- Monitor JavaScript-heavy sites with browser rendering
- Set up sophisticated filters and detection rules
- Access sites from server locations worldwide
- Store unlimited change history
- Monitor sites requiring cookies or sessions
- Bypass rate limiting with smart scheduling
How Server Mode works
- Set up ChangeDetection.io: install on your own server or use their cloud service.
- Connect Notify!: enter your server URL and API key in Notify!'s settings.
- Enhanced monitoring: your server handles the heavy lifting while Notify! delivers instant push notifications.
- Both halves: the server does the watching, Notify! does the notifying, on whichever devices you use.
- Websites only: a server takes over site watching. Feeds are still read by the app on your device, and in Server Mode that happens while the app is open or when you pull to refresh, not on the background schedule.
Benefits of Server Mode
- Monitor sites that block direct device access
- Check sites more frequently without rate limiting
- Use advanced features like visual selectors and regex filters
- Keep monitoring even when your device is offline
- Share monitoring across multiple devices seamlessly
Quick wins
Quick troubleshooting tips
If a site isn't working in Notify!
- Try monitoring a simpler page on the same site (like the homepage instead of a product page).
- Check if the site loads normally in Safari on your device.
- Wait a few hours and try again. It might be temporary.
- Consider using Server Mode for problematic sites.
- Reduce check frequency to avoid rate limiting.
If a feed isn't notifying you
- A feed you have just added is quiet on purpose. The first check records where the feed stands and sends nothing, so you hear about posts published after you added it.
- Timing comes from the single Check Interval in Settings, 15 minutes at its shortest. Every feed shares it, so changing it changes all of them.
- In Server Mode, feeds refresh while the app is open or when you pull to refresh. Only Local Mode refreshes them on the background schedule.
- A paused feed still shows in the list but is not being checked.
- A failed check puts a red Error pill on the feed in the list. The reason itself is on that feed's own screen.
- A burst of posts gives you the 5 newest from that check, not one notification per article.
- Deleting a feed forgets which items it had already seen, and re-adding it stays quiet until the site publishes something new. Pause it instead if you only want a break.
- Still stuck? The feeds section above covers discovery, formats and what feeds cannot do.
Sites that typically work well
- News websites and blogs
- Government and educational sites
- Simple HTML pages and documentation
- Status pages and simple dashboards. If a site publishes a feed, add it under Feeds rather than watching the page: you get the post title and a link instead of a diff of raw XML, and only new items notify you.
- Most company websites and portfolios
Get in touch
Still need help?
Our support team is here to help you get the most out of Notify! Send us your questions and we'll get back to you as soon as possible.