Activity and Operations

Activity records confirmed catalog changes and collection-ready events. Settings > Operations explains monitoring, delivery, storage, and security health. Operations is the last Settings subtab; old #operations links still route there.

Activity filters and pages

Search by product/name identity and combine type, region, date, and delivery filters. The feed includes restocks, sellouts, price changes, status changes, new products, and collection-ready events. Open an entry to inspect its evidence and notification outcome or to open the associated item/collection.

In current dev, teal NEW TO STORE badges identify newly detected listings in the monitored regional catalog, with their availability at detection (such as Coming soon or In stock). NOW AVAILABLE marks a Coming soon → In stock event; its waiting duration reads Coming soon for. Ordinary restocks retain Back after and have no discovery badge. Upcoming listings show Still coming soon while that remains their confirmed current status. Each parent product and exact variant remains a separate compact card. Badges describe the original event and remain if the separate current availability changes; they do not establish a manufacturer's release date. Open a card for the full explanation.

Entries per page defaults to 20, with 50 and 100 options. The browser remembers your choice. Use Previous and Next for additional entries; changing a filter or page size returns to page 1. Activity is an event log, so a row can exist even when no notification was due.

CSV and JSON exports use the selected filters and include at most 10,000 matching events. Narrow the date/region/type filters when exporting larger histories. Exports contain product/activity information and are private owner data; they are not redacted support bundles.

Reading during background updates (current dev)

Activity keeps the page you are reading when new events arrive. New activity available shows the number of new matching events; selecting it loads the latest first page. Previous/Next retain the current snapshot boundary, so new events do not move entries between pages. Search, filter, and page-size changes start a new snapshot. Delivery outcomes on the same rows may refresh in place. If changed delivery filters, retention, or recovery alter which rows belong on the page, Activity changed · Refresh lets you reload it explicitly.

This is a temporary reading position, not read/unread tracking. A page reload starts a fresh snapshot. Exports include current matching history independently of the displayed snapshot. These changes are available in the current dev checkout, not published v1.2.0 downloads.

Delivery outcomes

Open event details to distinguish a suppressed event from one that is queued, delivered, or failed. Quiet hours, digest scheduling, cooldowns, pauses, purchased watches, and collection-only overrides can all affect delivery. Queue/log details show channel outcomes and failure evidence; one channel's successful delivery does not mean every channel succeeded.

Fix a channel's underlying configuration or connectivity issue before retrying failed jobs. Some changes intentionally cancel pending/failed notifications, such as marking a watch purchased or enabling a collection-only override; cancelled jobs are not catch-up notifications.

Overall health

The Operations page starts with an overall Healthy, Degraded, or Action Required state and links actionable warnings to the relevant Settings tab. The same highest-priority issue appears in a compact owner-attention banner throughout the dashboard. Operations also includes every region's last/next check, product and watch counts, catalog errors and pending confirmations, notification queue outcomes and next delivery, primary and secondary recovery status, database/free-space sizes, security warnings, filtered downloadable logs, runtime architecture, commit, and container image information.

Operational alert switches can notify about repeated store-check failures, exhausted delivery attempts, backup failures, and low disk space. The on-screen issue remains useful when an external channel is unavailable.

Diagnostics and support bundles

Run diagnostics checks database integrity, data/backup directory access, local encryption-key decryption, non-destructive restore readiness, free space, notification failures, store connectivity, and access-mode security. Support bundle downloads a redacted JSON snapshot of runtime health, recent checks, configuration state, queue summaries, and application logs. It excludes passwords, tokens, webhook URLs, local filesystem paths, host addresses, and product/watchlist data.

Run diagnostics after initial setup and after storage, mount, access-mode, or channel changes. A restore test uses temporary recovery data and does not replace the live database. Review even a redacted bundle before sharing it. Raw logs, Activity exports, database backups, and screenshots can contain private information.

Health endpoints

Endpoint	Authentication	Meaning
GET /healthz	No owner session	Process is alive; returns basic name/version and HTTP 200
GET /readyz	No owner session	HTTP 200 when all enabled regions have recent successful data and no current error; otherwise 503
GET /api/health	Owner session in authenticated modes	Detailed monitor health

Host/origin validation still applies to health requests. Mock mode reports ready without contacting real Stores. Use liveness for process supervision and readiness to assess fresh catalog data; an upstream outage is not necessarily a reason to repeatedly restart a healthy process.

Updates and maintenance

Check for updates reads GitHub Releases (or a configured manifest) and shows notes and download links. Prepare safe update flushes current state, creates and validates a pre-update backup, and displays the platform command. GearBeacon never performs an unattended update.

Continue with Updates and rollback, Backups and recovery, or Troubleshooting.