Blog
Push notifications for forms: why email alerts aren't enough
· 3 min read
The default notification channel for form submissions has always been email - and email is where urgency goes to die. The alert lands between a newsletter and a receipt, sometimes in spam, often noticed hours later. For a business enquiry, response time is conversion: the lead that gets a reply in five minutes remembers you; the one that waits a day has already emailed your competitor.
Web push notifications fix the channel. Here's how they work and what to look for.
What web push actually is
Web push is a browser standard (the Push API plus service workers) that lets a website deliver system-level notifications - the same native banners and notification-center entries that installed apps produce. Three properties make it ideal for form submissions:
- It works with the browser closed. The service worker receives the push and the OS displays it; no tab needs to be open.
- It's cross-platform. macOS, Windows, Linux, Android - and iOS when the site is installed as a PWA (Apple requires the home-screen install for push).
- It's opt-in and per-device. You grant permission once per device you actually want pinged.
Under the hood: your browser registers a push subscription with its push service, the form backend stores that subscription, and when a submission arrives it sends an encrypted payload that wakes the service worker. All of it is web standards - no app store, no phone numbers, no third-party messenger.
What it looks like in practice
With Formhook, a submission to any of your forms produces a native notification within moments of the POST - title, form name, and a preview of the message. Setup is a permission prompt in the dashboard: click "enable notifications," accept, done. Per-form mute means the busy newsletter form can stay quiet while the "new client enquiry" form stays loud. (Technical detail in the push docs.)
The homepage demo shows the loop end-to-end: submit the demo form, get the ping. It's the fastest way to understand why this beats email - you feel the latency difference.
The iOS caveat, honestly
On iPhone, web push only works after the site is added to the home screen as a PWA - a genuine extra step Apple imposes on all web apps. Once installed, notifications behave like any app's. If your workflow is Android, desktop, or laptop, there's no caveat at all.
What to check in any form backend
- System push, not just "browser notifications" - the notification must arrive with the browser closed, or it's decoration.
- Per-form control - mute granularity matters the moment you run more than one form.
- Email as a fallback, not the only channel - email still has a role: it's the paper trail. Push is the pager.
- No extra cost - being told a lead arrived shouldn't be a premium feature. In Formhook, push is on every tier including Free.
The pattern that works: push for speed, dashboard for handling, email for records. Set it up once and the "sorry for the late reply" era quietly ends.
Ship a working form in one line
EU-hosted, submissions kept forever, push notifications on every tier.
Start freeNo credit card · read the docs
Keep reading
- What is a form backend? (And when you need one)A form backend receives, stores, and forwards your website's form submissions so you don't run a server. Here's how they work and when you need one.
- Contact form testing: the pre-launch checklistA broken contact form fails silently and costs leads for weeks. The 15-minute pre-launch checklist: happy path, validation, spam, mobile, and notifications.
- Google Forms vs a real contact form on your websiteGoogle Forms is free and easy - but embedding it on a business site costs you branding, UX, and data control. When it's fine and when to use a native form.