Web push alerts let your browser receive notifications about agent failures, budget thresholds, and task outcomes even when the dashboard tab is not open. Once a user opts in, the operating system delivers notifications directly — no need to keep the tab active or check email. For teams operating AI agents throughout the day, this means critical signals reach operators as they happen rather than when someone thinks to look.
Why browser push matters for AI operations
Email and in-app notifications both require the recipient to be actively looking somewhere. A budget cap being hit at 2pm on a busy day might not surface in a team member's inbox until 4pm — after a runaway agent has consumed hours of compute budget. AI operations demand a tighter feedback loop. For context on the broader alerting landscape, see Slack and multi-channel alerting.
Browser push notifications close this gap by reaching the user regardless of what they are currently doing on their computer, as long as the browser is open. The notification appears at the operating system level, the same way a calendar alert or a message from a chat tool does. Users can glance at it and dismiss, or click through to the relevant item in the dashboard.
The practical effect is that your on-call operator or platform administrator does not need to stay parked on the dashboard to stay aware of what the agent fleet is doing.
How the Web Push protocol works
Web push is a browser standard built on the VAPID protocol. The mechanism involves three parties: the browser, the platform's backend, and the browser vendor's push service (operated by Google, Apple, Mozilla, or Microsoft depending on the browser).
When a user opts in to push notifications, the browser generates a subscription object that contains a unique endpoint at the push service and a pair of encryption keys. The platform stores this subscription and uses it to send encrypted messages through the push service to the user's browser. The browser vendor's infrastructure handles delivery; the platform never has direct access to the user's device or credentials.
Messages are encrypted end-to-end: only the browser that holds the private key can decrypt them. The push service knows a message is being delivered but cannot read its content. This is the same architecture that underlies push notifications in mobile apps, adapted for the web.
Opting in from your notification settings
The opt-in flow is straightforward. From your profile's notification settings, you toggle push notifications on. The browser prompts you to grant notification permission — a one-time operating-system-level grant per browser. Once granted, your browser is registered to receive push messages from the platform, and the subscription is stored against your account.
You can opt out at any time from the same settings page, which unregisters your browser and removes the stored subscription. If you deny the browser permission prompt, push will not be available in that browser until you manually re-enable it via the browser's site permissions.
Subscriptions are per-browser, per-user. If you access the platform from multiple browsers or devices, each needs its own opt-in. This is a browser platform constraint rather than a platform-specific limitation.
Which events trigger push notifications
Push notifications are generated by the same event that creates an in-app notification. The notification type determines relevance: agent task failures, budget threshold breaches, workflow run completions, and connection status changes are all candidates. When the platform creates an in-app notification for a user, it also delivers a push message to each of that user's registered browser subscriptions.
This means you do not configure push notifications separately from in-app notifications. The notification settings that control which events generate in-app notifications are the same ones that feed push delivery. Turning off a notification type for in-app also turns it off for push, and vice versa.
The result is a single, consistent notification policy per user rather than two parallel systems to maintain. For a broader look at how real-time events surface across the platform, see in-app notifications that cut through.
Delivery characteristics and what to expect
Push delivery is best-effort by design, which is a property of the protocol rather than a platform constraint. The browser vendor's push service does not guarantee delivery timing, and messages that cannot be delivered while the browser is offline may expire before the browser reconnects. In practice, for short-lived events like a budget alert or a task failure, this means push notifications are a near-real-time signal rather than a durable one.
For events that require guaranteed acknowledgment or audit records, the in-app notification center and the audit log are the authoritative sources. Push is a convenience layer that surfaces the signal at the moment it is most actionable. When you click a push notification and navigate to the dashboard, the underlying item — the failed task, the breached threshold — is waiting in the in-app notification feed with full context.
Teams that need guaranteed delivery for critical alerts should complement push with email notifications or integrate with their existing alerting infrastructure via the platform's event stream — see webhooks and SIEM forwarding for how to route events into external systems.
Subscription lifecycle management
Push subscription lifecycle is managed automatically by the platform. When a browser subscription becomes invalid — because the user cleared their browser data, switched browsers, or the push service rotated the endpoint — the platform detects this at delivery time and removes the stale subscription rather than accumulating dead entries. Re-enabling push from settings registers a fresh subscription.
The subscription store is scoped to the user. Administrators do not have visibility into individual users' push subscriptions, consistent with the privacy boundary between a user's personal notification preferences and platform-level administration.
For platform administrators, the relevant control is not in push settings but in notification policy: which events generate notifications, and for whom. Those controls live in the notification and alert configuration surfaces. For a related perspective on real-time event delivery at the platform level, see real-time events over WebSocket.
Common questions
Does push work when the browser is fully closed? No. Browser push notifications require the browser to be running, though not necessarily in the foreground or with the dashboard tab open. If the browser is fully closed, notifications queue at the push service and may expire before the browser reconnects, depending on the time-to-live set by the push service. For critical alerts, email notifications provide a more reliable fallback.
Can I receive push notifications on my phone? Mobile browser push works on Android browsers that support the Web Push standard. On iOS, Safari supports Web Push for websites added to the home screen. The experience varies by browser and operating system version. The platform's push implementation follows the standard Web Push protocol, so support depends on the browser you use on your mobile device.
What happens to my subscription if I change browsers or reinstall? Each browser installation generates a new subscription. Changing browsers or reinstalling means your previous subscription is no longer valid, and push delivery to that browser will silently stop from the browser's side. The platform detects the stale subscription at the next delivery attempt and cleans it up automatically. To resume push on your new browser, visit notification settings and opt in again.
How does push fit alongside other alert channels for AI operations? Push is best for immediacy — it surfaces alerts at the OS level without requiring the recipient to be in any particular application. Email provides a durable, searchable fallback for recipients who are away from their desk or have the browser closed. Slack and other webhook-based channels work well for team-visible alerts where multiple people need to see the same signal. The most resilient setup uses push for the operator on call, email as the fallback, and Slack or a webhook integration for team-level visibility. For how to route alerts into external channels, see webhooks and SIEM forwarding.