Metabase Alerts
You set up metabase alerts by attaching a schedule and threshold to any saved question. When the query results cross that line, the app sends a notice over email or chat. Most teams set up these rules using one shared database account for the whole reporting tool. If that shared role has broad permissions, any alert query can read sensitive tables without limits. How metabase alerts work under the hood An alert starts with a saved question that returns a number or a list of rows. A team membe
Slack Bots for Security Alerts: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up metabase alerts by attaching a schedule and threshold to any saved question. When the query results cross that line, the app sends a notice over email or chat. Most teams set up these rules using one shared database account for the whole reporting tool. If that shared role has broad permissions, any alert query can read sensitive tables without limits.
How metabase alerts work under the hood
An alert starts with a saved question that returns a number or a list of rows. A team member picks a condition, such as when rows appear or a metric drops. A background job runs the query on a set timer to check the latest data. If the results match the rule, the system builds a message and sends it out.
To run these background checks, the reporting app uses its stored database login credentials. It does not use the personal database identity of the user who made the alert. Instead, every background check shares the same pool of database sessions. That single database role must have read access to every table used by any alert.
The app also attaches a snapshot or table of results to the alert message. If the underlying query pulls customer rows, those rows go straight to email or chat channels. Anyone in that chat room can read the rows that triggered the notice. The native setup relies on folder and collection rules inside the app to manage visibility.
What native alert setup solves and what it leaves open
Native rules let teams spot drops in sales or spikes in error counts right away. Analysts do not need to open dashboards every morning to check if numbers look right. Folder rules inside the reporting tool also control who can view or edit saved questions. For basic metrics that only send totals, the built-in workflow handles the job well.
The gap appears inside the database session itself when background queries run. Native setup decides who logs into the app, not what individual queries do in flight. Because the reporting tool uses a shared database role, database logs only show one generic user. Security teams cannot tell which analyst wrote an alert that scanned a sensitive table.
Slack Bots for Security Alerts: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Broad database roles also mean an alert query can pull raw customer records by mistake. If an alert checks failed orders, the result set might include emails or phone numbers. Native app permissions do not rewrite matched fields in results before they leave the database. Unmasked card numbers or national IDs can end up in shared chat rooms or inboxes.
Managing query behavior and data exposure for background checks
To reduce risk, teams often create a read-only database user just for the reporting app. They grant this user access only to specific schemas or summary views. This step blocks the app from changing data or reading system tables. Still, summary views take time to maintain when analysts need fresh columns for new alerts.
When analysts need access to raw tables, static database grants fall short. A table with order data often holds both safe metrics and sensitive contact details. Database roles grant access at the table or column level, not per query context. Teams need a way to inspect each query and mask sensitive fields in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What types of questions support metabase alerts?
Alerts work on questions that return raw rows, a single number, or a progress bar. You can also set them on line, bar, or area charts that have a goal line.
What happens when someone edits a question that has an alert?
If a change breaks the chart type or removes the goal line, the alert stops working. The app notifies the people on the alert list when a change disables their rule.
How can teams stop alerts from sending sensitive customer data to chat channels?
Teams should restrict the reporting database role from reading raw sensitive columns directly. Putting dynamic data masking in front of the database also rewrites emails and phone numbers in results.