Repository navigation
Alerts and Notifications
Configure server channels and scheduling in Settings > Notifications, per-watch behavior through Alert rules, and project readiness through a collection's Alerts button. Monitoring and server delivery do not depend on an open browser.
- Configure a channel in Settings: ntfy, Discord, Gotify, SMTP email, or a generic webhook.
- Enable that channel and run its individual test.
- Choose global event types and scheduling, then save.
- Set any watch overrides, preview the rule, and review delivery outcomes in Activity or Settings > Operations.
A successful test confirms that channel's current delivery configuration; it does not establish that a stock event meets a watch rule. Email and webhooks covers integration details. Browser popups are separate: they require browser permission and a running dashboard page.
Channel configuration, delivery timing, previews, and individual test buttons are in Settings. A channel can be configured but independently disabled. Restock alerts for watched products are enabled by default; sellout, price, status, and new-product alerts are opt-in. The separate All activity updates option alerts for every new Activity feed entry, including changes to unwatched products, and overrides the individual event filters while enabled. It is disabled by default to avoid unexpected notification volume.
Each watched product can inherit those global event choices or override them. Product rules can limit price notifications to drops, wait for a target price, pause alerts, or force restocks to deliver immediately. Immediate restocks bypass quiet hours and digest scheduling. Other queued events can be held until quiet hours end, collected for the next daily digest, and suppressed during a configurable per-product event cooldown.
After watching an item, set a target price and enable Alert when available at or below the target price to combine both conditions. This replaces the separate restock and price-change choices for that watch. A qualifying restock alerts immediately; a price reaching the target while available needs the normal two complete observations. The rule alerts once per qualifying period and rearms after confirmed observations no longer meet the condition. For an Any variant watch, stock and price must match on the same variant. Its notification identifies that matching variant. Prices use the selected Store's currency and the catalog display price; shipping, taxes not already included in that price, and checkout surcharges are not calculated.
Preview rule & notification evaluates the unsaved rule without recording activity or delivering an alert. Existing quiet hours, digests, cooldowns, and immediate-restock settings still apply. All activity updates, when enabled, continues to override event filters and combined conditions; the preview calls this out. Purchased watches remain stopped, and an enabled Collection alerts only override still suppresses individual notifications.
Saving/enabling a condition establishes its current baseline rather than delivering a catch-up alert for something already qualifying. Use the preview to understand the proposed rule, and allow a fresh complete check after configuration or recovery.
Open Alerts on a collection card, at the bottom of its details or editor, or beside it in Manage collections, then enable Notify when all remaining items qualify to receive a server-side alert when it enters readiness. The toggle saves automatically in its own view. New collections must be created before configuring alerts. When opening alerts from the editor, they apply to the saved collection; use Back to editing and Save changes to apply pending name or membership edits. The default Collection and item alerts mode keeps both kinds of notification enabled; pausing an item does not pause the collection alert. Enabling the option establishes the current baseline, so an already ready collection does not alert immediately. The alert fires once per qualifying period, survives restarts and recovery, and rearms only after confirmed observations show the collection is no longer ready. Monitoring gaps never rearm it. Empty and fully purchased collections never alert. Each opted-in collection has its own transition alert, including overlapping collections.
Choose Collection alerts only under Individual item alerts to suppress individual notifications for this collection's members while its readiness alert is enabled and the collection is active. This selection saves automatically. Item rules remain saved, including event choices, targets, and pauses. If any active containing collection has this mode and alerts enabled, it suppresses that item's notifications, including All activity and immediate restocks; item cards, collection rows, and the rule editor name the responsible collections. Other collections still send their own opted-in readiness alerts. Disabling the last override, turning off its readiness alert, or removing the last suppressing membership restores future notifications under the saved item rules. Pending and failed individual deliveries are cancelled when the override takes effect and are not replayed when it is removed; a delivery already in progress may finish.
Collection alerts use configured notification channels, quiet hours, grouping, digests, cooldowns, and bounded retries. They appear in Activity under Collection ready, with an action to open that collection. They are separate from individual watch pause settings; All activity does not enable them. Disabling or deleting a collection, changing its membership, or changing a member's target, desired quantity, or purchased quantity cancels pending/failed collection jobs and establishes a new baseline. A delivery already in progress may finish. Notification contents describe the conditions observed when the alert was queued; check the Store for current availability.
| Situation | Individual item notifications | Collection readiness notification |
|---|---|---|
| Collection and item alerts | Use the watch's saved rules | Sends on an opted-in readiness transition |
| Collection alerts only, readiness enabled, active project | Suppressed for members | Sends on the collection's transition |
| Individual watch paused | Paused | Still evaluates the project's remaining items |
| Collection archived | Saved watch rules apply unless another active override suppresses them | Inactive; saved settings retained |
| Empty or fully purchased collection | Depends on each watch's own state | Never sends a readiness alert |
Quantities, targets, spending, archive state, and collection grouping are explained in Purchase planning.
Collection Alerts includes Only notify when this collection is within budget. With readiness notifications enabled, it adds the saved project budget to the stock and shared per-item target conditions. Recorded spending plus the confirmed cost of remaining units must fit the budget. Unknown payments, missing/pending prices, stale checks, and an unset budget cannot qualify. The condition is off for existing collections and does not change individual item rules or the selected collection-only override.
Editing conditions establishes a fresh baseline and cancels obsolete pending/failed collection alerts. A confirmed transition out of qualification is required before another ready alert; uncertain observations cannot rearm one. See budget calculation and variants for examples and limits. This feature is not in published v1.2.0 downloads.
Scheduling uses the configured IANA timezone. Native installations start with the system timezone; the supplied Compose defaults to UTC. Quiet hours and daily digests are off by default. Their initial times are 22:00–07:00 and 09:00 respectively, and the default cooldown is 30 minutes. A grouping window of 0 means grouping is disabled.
Use the scheduling preview in Settings to review when a normal event would be delivered. An immediate-restock rule bypasses quiet hours and digest timing; it does not bypass a purchased watch or an active collection-only suppression. Collection-ready notifications follow their normal configured schedule.
Normal events are written to a persistent SQLite queue before delivery. Failed attempts use exponential backoff up to the configured limit. Operations shows pending/delivered/failed counts, failure reasons, and an owner-controlled retry action. The optional grouping window combines nearby events for the same region and channel.
The default maximum is five attempts. Correct a channel's credentials/network/TLS issue before using the owner retry action. A queued notification describes what was observed when queued, so a delayed message can differ from the Store's present stock or price.
Cancelled pending/failed jobs are not replayed merely because a pause, purchase, membership, or collection override is later changed. A delivery already in progress may finish. Activity records confirmed changes even when notification rules decide not to send.
Settings can enable alerts for repeated monitoring failures, exhausted notification delivery attempts, backup failures, and low disk space. These switches default on, but delivery still needs a configured channel. Operations also shows the problem in the dashboard. A broken channel cannot be relied on to report its own failure successfully.
The current development checkout adds a saved-rule summary to watch and collection cards, with Why? opening an accessible explanation. This is not included in the published v1.2.0 download.
The explanation distinguishes rule configuration from notification delivery:
- Current rules: purchased/paused/disabled state, inherited global choices, targets, active collection-only overrides, and enabled server channels. All activity can override individual pauses and event filters, but purchased watches and active collection-only suppression still take precedence. Pausing an item does not pause collection readiness.
- Delivery timing: a preview for a new matching event using the installation's notification time zone. It identifies immediate restocks, grouping, quiet hours, or digest timing and lists active repeat-event cooldowns. This preview does not enqueue anything.
- Actual notification jobs: up to 20 recent pending, processing, or failed jobs for that specific watch/collection in the selected Store. These show the channel, job state, timing, and attempts. Jobs already queued can differ from the current rule configuration; use Activity and Operations for history and retry actions.
An enabled rule does not mean an alert is queued, that a target is currently met, or that stock is guaranteed. With no enabled server channel, the summary explains the delivery limitation. Browser popups still require an open page and permission. Changing a collection override refreshes its members' summaries immediately.
Wiki home · Troubleshooting · Source repository · Releases · Report a security issue privately
Documentation covers GearBeacon 1.2.0 and the current source layout. GearBeacon is independent and is not affiliated with or endorsed by Ubiquiti Inc.
Start and install
Use GearBeacon
- Watchlist and Browse
- Collections and purchases
- Auto-buy setup and verification (dev)
- Alerts and notifications
- Email and webhooks
- Stock insights
- Activity and Operations
Configure and maintain
- Configuration reference
- Security and access
- Reverse proxy
- Backups and recovery
- Updates and rollback
- Troubleshooting
Develop