Skip to content

Notification triggers: the discontinued showTrigger / TimestampTrigger proposal

In one line: Notification triggers were a Chrome proposal that would have let a site schedule a notification to fire at a future time — via a showTrigger option holding a TimestampTrigger — but Chrome’s own documentation now says development of the API “has ended,” and showTrigger/TimestampTrigger do not appear among MDN’s documented showNotification() options.

Chrome’s documentation says Periodic Background Sync’s refresh cadence “isn’t sufficient” for pruning a scheduled notification that has gone stale or been invalidated while no tab is open, and separately notes that “the Push API isn’t a good solution either,” since network connectivity or battery-preserving features like doze mode can delay push-based notification delivery. Notification Triggers aimed to let the browser itself hold a scheduled notification and fire it at the right moment.

async function scheduleNotification(registration, delayMs) {
await registration.showNotification('Scheduled notification', {
showTrigger: new TimestampTrigger(Date.now() + delayMs),
});
}

A companion includeTriggered flag was needed on getNotifications() to retrieve not-yet-fired scheduled notifications, for example to let a user cancel one before it appeared.

Chrome’s own documentation showed detection like this. The else branch below is not from Chrome’s docs — showTrigger support cannot be assumed, per Chrome’s own “development has ended” notice and its absence from MDN’s current showNotification() options list. The fallback below notifies immediately and says so:

async function scheduleNotification(registration, delayMs) {
if ('showTrigger' in Notification.prototype) {
await registration.showNotification('Scheduled notification', {
showTrigger: new TimestampTrigger(Date.now() + delayMs),
});
} else {
// showTrigger cannot be assumed to exist. Sites need a server-driven
// mechanism (e.g. Web Push, see "Where to go next") for real future
// delivery. Notify now and say so, rather than implying scheduling this
// fallback can't provide.
await registration.showNotification('Scheduled notification', {
body: 'This notification could not be scheduled for later; showing it now instead.',
});
}
}

Chrome’s developer documentation carries a notice stating that development of the Notification Triggers API “has ended,” with the stated reason: “It wasn’t clear that we could provide consistent and reliable experiences across platforms.” MDN’s current reference for ServiceWorkerRegistration.showNotification() documents its options object (actions, badge, body, data, dir, icon, image, lang, navigate, renotify, requireInteraction, silent, tag, timestamp, vibrate) without listing showTrigger or TimestampTrigger among them.

  • Treating Chrome’s page as a live API reference. The code samples still describe how the flagged, origin-trial version of the API worked, but Chrome’s own notice says the underlying development effort has ended.
  • Assuming it’s interchangeable with Push or Periodic Background Sync. Chrome’s documentation raises specific, separate limitations of each — Periodic Background Sync’s cadence for pruning stale scheduled notifications, and Push’s exposure to connectivity and doze-mode delays — rather than treating this proposal as a drop-in replacement for either.
  • Do not build production features around showTrigger / TimestampTrigger — Chrome’s own documentation states development has ended.
  • Feature-detect with 'showTrigger' in Notification.prototype only if deliberately targeting the historical, flagged experiment.
  • Check MDN’s current showNotification() options reference before assuming any given notification-scheduling option is available — showTrigger is not among them.
  • Re-read Chrome’s status notice before citing this API in new work; a “development has ended” notice can be updated to reflect a different status later.