Skip to main content

​
When Rules Are Triggered

Rules run automatically during family syncs or can be triggered manually. Understanding when rules execute helps troubleshoot categorization issues.
Rules can be manually triggered in the following ways:
  • Clicking “Re-apply” on an individual rule in /settings/rules
  • Clicking “Apply All” in /settings/rules
  • Running the rake task: bin/rails rules:apply_all[family_id]
Rules with active: true run automatically when a family sync occurs (Family::Syncer.perform_sync):Scheduled syncs:
  • SyncAllJob - runs daily at 2:22 AM for all families
  • SyncHourlyJob - runs every hour (for items that opt-in to hourly syncing)
Triggered syncs:
  • Provider webhooks (Plaid, etc.) - triggers sync which eventually propagates to family
  • Manual sync button on accounts page
  • After CSV imports complete (Import model calls family.sync_later)
Rules are not triggered in these scenarios:
  • Manual transaction creation - Only triggers an Account sync (not Family sync)
  • Manual transaction editing - Same as above, only Account sync runs
  • Inactive rules - Rules with active: false never run automatically, only via manual “Re-apply”

​
Category Rule Popup Behavior

When a user selects a category for a transaction, a popup may appear to create an automatic categorization rule. This popup is intentionally gated by several conditions:
The popup only shows when all of these conditions are met:
  1. User has not disabled rule prompts (rule_prompts_disabled is false)
  2. User hasn’t dismissed the popup in the last 24 hours
  3. The transaction category actually changed
  4. No existing rule already sets this category for similar transactions
  5. The transaction has a category assigned
Check these common reasons:
  • Recently dismissed: Wait 24 hours after dismissing the popup
  • Rule already exists: A matching rule may already be in place
  • Prompts disabled: Check if rule_prompts_disabled is enabled for the user

​
Sure Doesn’t Work Over HTTPS

If Sure behaves incorrectly or fails when accessed over HTTPS, it’s usually due to missing SSL-related configuration between Nginx and Rails.
Sure relies on correct protocol headers to determine whether a request is secure.
When HTTPS is terminated at Nginx but not properly forwarded to the app, Rails may treat requests as HTTP.
Apply the following configuration changes:
  1. Nginx Ensure HTTPS is forwarded to the upstream app: 
    proxy_set_header X-Forwarded-Proto https;
  2. docker-compose.yml In the x-rails-env: &rails_env section, set: 
    RAILS_ASSUME_SSL: "true"
    This tells Rails to treat all requests as HTTPS.

​
Some pages break over HTTPS

Sure uses WebSockets for certain pages. If some pages fail to render correctly or break entirely, this is often caused by missing SSL or upgrade headers in your reverse proxy configuration.
You may see pages partially load, fail completely, or errors similar to:
Failed to upgrade to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: close, HTTP_UPGRADE: )
This indicates that the WebSocket upgrade request is not being forwarded correctly.
Ensure your Nginx configuration includes the required WebSocket headers:
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
These headers allow Nginx to properly handle WebSocket upgrade requests over HTTPS.