Docs: update for recent feature releases

guides/app-features/transactions.mdx

@@ -94,6 +94,37 @@ Sure prevents merges that would make the category hierarchy confusing or invalid
 
 If a source category has subcategories and the target is a parent category, Sure reparents those subcategories under the target.
 
+## Transaction rules
+
+Rules let you automatically apply categories, merchants, tags, and other attributes to transactions that match a set of conditions. You can create and manage rules from **Settings → Rules**.
+
+### Condition types
+
+Rules support the following condition types:
+
+- **Transaction name** – match on the transaction name or description
+- **Amount** – match on the transaction amount
+- **Account** – match on the account the transaction belongs to
+- **Category** – match transactions that already have a specific category assigned, or that have no category
+- **Merchant** – match on the merchant associated with the transaction
+- **Tag** – match transactions that already have a specific tag applied, or that have no tags
+
+The tag condition uses **Equal to** and **Is empty** operators, matching the same pattern as the category and merchant conditions. When you combine multiple tag conditions with AND, each condition is evaluated independently, so a transaction with both tags will match correctly.
+
+### Rule actions
+
+Rules can set:
+
+- Category
+- Merchant
+- Tags
+- Notes
+- Name
+
+### Applying rules
+
+Rules run automatically during account syncs. You can also apply rules manually from **Settings → Rules** using **Re-apply** on an individual rule or **Apply All** to run every active rule against your existing transactions.
+
 ## Related pages
 
 - [Budgets](/guides/app-features/budgets)

providers/lunchflow.mdx

@@ -104,3 +104,11 @@ LUNCHFLOW_DEBUG_RAW=1
 - Subject to Lunch Flow API rate limits
 - Holdings data not available for all account types
 - Coverage varies by country and institution
+
+## Troubleshooting
+
+### Pending transactions stuck with a "Pending" badge
+
+Lunch Flow assigns stable IDs to most transactions. When a transaction moves from pending to posted under the same ID, Sure detects that the stored snapshot has changed and refreshes it automatically on the next sync, clearing the pending status.
+
+Some pending transactions from Lunch Flow have no ID. Sure deduplicates these by content hash within a single sync response, so two genuinely identical purchases in the same response are each preserved rather than collapsed into one. If a pending transaction with no ID is still showing after it has posted, trigger a manual sync to force a fresh fetch.

providers/overview.mdx

@@ -74,6 +74,8 @@ Available providers include Yahoo Finance, Twelve Data, Tiingo, EODHD, Alpha Van
 - **Pricing**: Paid service (API access requires a Redbark Developer or Professional plan)
 - **Documentation**: [Redbark](redbark)
 
+**Up** bank accounts can be connected through Lunch Flow. Sure automatically maps Up's category slugs to your existing Sure categories on import, so transactions arrive pre-categorised based on the tags you've already set in the Up app. Categories you've manually set or locked in Sure are always preserved during re-syncs. Up-specific categories with no clear Sure equivalent (such as Booze, Pets, or Life Admin) are left uncategorised so you can apply your own rules or AI categorisation.
+
 ## Cryptocurrency providers
 
 ### Binance

providers/simplefin.mdx

@@ -102,6 +102,10 @@ Generate a new setup token from your SimpleFIN dashboard.
 
 Some institutions don't return pending transactions even when the `pending=1` parameter is set. This is a limitation of the institution's data feed, not a bug in SimpleFIN or Sure.
 
+### Duplicate accounts with the same name
+
+If you have two distinct accounts at the same institution that share a display name (for example, two accounts both named "CHECKING (0001)"), Sure uses the upstream account ID to distinguish them during sync. Only accounts whose ID is genuinely absent from the upstream response are treated as stale and eligible for re-linking. Ambiguous cases where multiple local accounts share a name are skipped rather than resolved automatically, preventing one account from silently inheriting another's transaction history.
+
 ### Network errors
 
 If you experience intermittent sync failures:

self-hosting.mdx

@@ -481,6 +481,46 @@ For production deployments:
 - Use `SMTP_OPENSSL_VERIFY_MODE=peer`
 - If you must use self-signed certificates, provide a CA bundle via `SSL_CA_FILE`
 
+## Monitoring system health
+
+When the Sidekiq worker container isn't running, background jobs silently never execute. Balance calculations, net-worth updates, and account syncs stall, and the UI may show zeros or "No balance data available" without explaining why.
+
+### Sidekiq health banner
+
+If Sure detects that Sidekiq is not processing jobs, a warning banner appears at the top of every page for super-admins. The banner indicates that data may be stale and links to the system health page.
+
+The check is conservative by design:
+- A worker process is considered stale if its heartbeat is older than 2 minutes, which tolerates brief deploy restarts and Redis blips.
+- A queue is considered backed up if its latency exceeds 5 minutes.
+
+The health snapshot is cached for 60 seconds to avoid extra Redis round-trips on every page load. You can override the thresholds and cache TTL with environment variables:
+
+```txt
+# Seconds before a worker heartbeat is considered stale (default: 120)
+SIDEKIQ_HEALTH_HEARTBEAT_TIMEOUT=120
+
+# Seconds of queue latency before the queue is considered backed up (default: 300)
+SIDEKIQ_HEALTH_LATENCY_THRESHOLD=300
+
+# Seconds to cache the health snapshot (default: 60)
+SIDEKIQ_HEALTH_CACHE_TTL=60
+```
+
+### System health page
+
+Super-admins can view live Sidekiq state at **Settings → Advanced → System health**. The page shows:
+
+- Worker process count and last heartbeat time
+- Maximum queue latency
+- Job counters (processed, failed, enqueued, retries)
+- Per-queue depth breakdown
+
+The system health page always bypasses the cache and fetches fresh state, so you can confirm a worker restart took effect immediately.
+
+<Note>
+The Sidekiq health banner and system health page are only available in self-hosted mode. Managed deployments do not show these features.
+</Note>
+
 ## Troubleshooting
 
 ### Database connection errors