How Metabase dashboard subscriptions reach Slack and inboxes without a Metabase login
Once email or Slack is set up, Metabase dashboard subscriptions send question results from a dashboard by email or Slack, including to people who do not have a Metabase account. That lets a team send a weekly sales summary or an operations snapshot to stakeholders who only need the numbers, not access to the instance. The feature is part of Metabase itself. It is not a separate connector you install, so the work sits in configuring the two delivery channels and deciding who should receive what. The two channels work differently. Email subscriptions send the results to addresses you or the subscriber enter, and the recipient reads them in an ordinary inbox. Slack delivery posts to a channel or to individuals through a Slack App. Metabase supplies a manifest for creating that app under Admin, Settings, Slack, and the person who completes that setup needs settings access in Metabase. Confirm which Slack workspace owner or administrator must approve the app in your environment before you schedule any deliveries. Before you enable recipients outside your organization, decide who owns each subscription. A subscription created by a departing analyst can keep running after that person leaves, so assign an owner and a review date to each one. Also confirm how your mail relay handles messages sent from the Metabase address, including sender authentication and any rate limits your provider applies, since a failed relay will look like a Metabase fault to recipients. On Pro and Enterprise plans, admins can restrict email subscription recipients to approved domains. On the open source edition and Starter, you have no such domain allowlist, so any address can receive results. Check the current plan comparison on Metabase's pricing page and the dashboard subscriptions documentation before you promise stakeholders a particular recipient model, because the controls available to you depend on the plan you run. Treat the data itself as the main risk. A dashboard that is safe for an internal analyst may expose more than intended when it lands in an external inbox or a broad Slack channel. Review which questions and filters each subscription includes, confirm that the data behind them is appropriate for every recipient, and test each subscription with a sample recipient before you schedule it. Your permissions model in Metabase governs what the subscription owner can see, so verify that the owner's access matches the audience.
What you need before configuring Slack and email delivery
Metabase subscriptions and alerts reach recipients through two outbound channels, email and Slack, and each needs a configuration step that an administrator completes. Confirm the items below before anyone opens the Slack or email settings, so setup does not stall partway through.
A self-hosted Metabase instance with an admin account
Delivery settings live in the Metabase admin area, so you need a self-hosted instance that you can reach from your admin workstation and at least one administrator account that can sign in. Confirm that the instance is running on the application database you plan to keep, because settings and subscription records are stored there. Record who holds the admin role, since that person will own the Slack app and the mail settings after go-live.
A working outbound SMTP configuration
Email subscriptions depend on the instance sending mail through an SMTP server you already operate or subscribe to. Before configuration, collect the SMTP host, port, encryption method, sending address and authentication details, and send a test message from the same network the Metabase server uses. A mail configuration that works from a laptop may still fail from the server, so test from the server itself.
A Slack workspace where someone can install apps
Slack delivery requires a Slack workspace in which a person can create and install a Slack App. Many workspaces restrict app installation to approved users, so confirm before the project starts whether your workspace owner or Slack administrator must approve new apps. Decide which workspace will host the app and which channels will receive subscriptions, because the app posts only where it is permitted.
Manifest-based Slack app setup by an admin
Metabase supplies a manifest for the Slack App under Admin, Settings, Slack, and the app is created from that file in Slack. Admins or people with settings access can complete this setup, so name that person before the work begins and confirm they can create the app in Slack. Keep the manifest file and the resulting app credentials in your organization's secrets store, not in a shared document.
Current Metabase version and mail relay requirements
Check the Metabase version support page for the release your instance runs and for the supported upgrade path before you change delivery settings. Ask your mail team which relay, sending domain, SPF, DKIM and DMARC records, and IP allowlisting your environment requires, because these rules decide whether messages from Metabase reach recipients. Get those answers in writing so the configuration matches your mail policy.
Configuring Slack and email subscriptions step by step
This sequence takes a self-hosted Metabase from no outbound messaging to a dashboard subscription that reaches an inbox and a Slack channel, including recipients without Metabase accounts. Each step ends with a check you can run yourself, so a failure can be traced to the step that caused it.
Configure email and send a test
An admin enters the outbound mail server details in Metabase's email settings and sends a test message to an address you control. Confirm with your mail team which SMTP host, port, encryption method and sender address your network allows, because Metabase can only deliver through a relay your environment permits. The step is done when the test message arrives in the inbox and the admin interface shows no send error.
Create the Slack app from the manifest
In the Admin area, open Settings and then Slack, and follow the flow that provides Metabase's Slack App manifest. Use the manifest to create the app in your Slack workspace, so you do not write the app configuration by hand. Confirm beforehand with your Slack workspace administrator that the person doing this is allowed to create apps. The step is done when the app appears in Slack's app list under the name you chose, with no errors shown in Slack.
Install the app and confirm posting
Install the app to your workspace, then complete the connection step that Metabase shows in its Slack settings after installation. Invite the app to a private test channel so that test posts stay away from business channels. The step is done when Metabase posts a test message to that channel and the message is visible to the people who should see it.
Create a dashboard subscription
Open the dashboard you want to share, choose the subscription option, and set the schedule and the content to include. Subscriptions send the question results on a dashboard, so check that each question returns data for the account that owns the subscription. The step is done when the subscription saves and appears in the dashboard's subscription list.
Add email and Slack recipients
Add one internal email address and the test Slack channel as recipients. External addresses can receive subscriptions once email is set up, even when the person has no Metabase account. On Pro and Enterprise plans, admins can limit email recipients to approved domains, so confirm the approved list with your security owner before adding outside addresses. The step is done when the subscription lists both recipients and saves without a validation message.
Check a delivered result
Trigger a send or wait for the scheduled time, then check the inbox and the Slack channel. Compare the figures in the delivered result with the same question on the dashboard to confirm the content matches. Record the subscription name, recipients and schedule in your change log so a later access or audit review can trace the setup. The step is done when the email arrives with the expected content and the Slack channel shows the posted result.
How subscriptions reach people without Metabase accounts
Recipients who do not have a Metabase account can still receive subscription results, because the delivery channel is what reaches them, not a Metabase login. Once email or Slack is set up, a subscription on a dashboard sends the results of its questions to the people or channels you choose. This makes the subscription an access path in its own right. Anyone who can read the destination can see the numbers, whether or not they could open the dashboard in Metabase. Before you enable a subscription, define the intended audience and confirm that the recipient list matches it.
Sending to a Slack channel and sending to an individual create different audiences. A message posted to a channel is visible to every current member of that channel, and it may also reach people who join later and can scroll back through the history. A message sent to one person's inbox reaches that person, who can forward it. For each destination, ask the channel owner who is a member and how membership changes. For email, check whether the address is a distribution group, a shared mailbox or an external address. Treat each destination as its own audience with its own owner.
The data in each result reflects the permissions of the question's creator and the delivery method you choose. A recipient outside Metabase has no Metabase permissions of their own, so the result they receive is shaped by the creator's access and by where it lands. A question built on broad data can therefore deliver more rows to a wider group than the dashboard was designed to show. Confirm in Metabase's dashboard subscriptions documentation exactly which permissions apply to each scheduled run. Then review every subscription's questions, destinations and schedule before it goes live, and again whenever someone edits a question.
Several controls depend on the plan and the setup. Slack delivery begins with a Slack App created from a manifest that Metabase supplies under Admin, Settings, Slack, and admins or people with settings access can complete that step. Limit who holds that access, and confirm which workspace the app is installed in and which channels it can post to. On Pro and Enterprise, admins can restrict email subscription recipients to approved domains. Check which plan your deployment uses before you rely on that restriction, and if it is unavailable, plan a manual review of external addresses.
Mapping dashboards, recipients and channels to delivery targets
This table maps each object in a Metabase dashboard subscription to the delivery target it reaches, the role that controls it, and what to check before go-live. Read each row from the source object on the left to the inbox or Slack channel on the right. The main takeaway is that recipient reach depends on several separate controls, so Metabase settings alone cannot confirm where messages land.
| Source object | Delivery target | Who controls it | Confirm in your environment |
|---|---|---|---|
| Dashboard or question | Attachment or inline result in the message body | Dashboard owner sets the subscription; admin sets email settings | Confirm which result format your Metabase version sends and how large results are handled |
| Subscription owner | Sender identity on the outgoing message | Admin configures the SMTP sender; the owner creates the subscription | Confirm whether the owner's name appears in the message or only in Metabase records |
| Email recipient | SMTP delivery to an inbox, including people without a Metabase account | Dashboard owner adds recipients; Pro or Enterprise admins can set approved domains | Confirm SMTP relay settings and that approved domains match your mail routing |
| Slack channel | Workspace channel the Slack App has joined | Slack workspace admin approves the app; channel members invite it | Confirm the app is installed in the workspace and invited to each target channel |
| Slack App credentials | Metabase connection to the workspace, created from the supplied manifest | Admin or a user with settings access runs setup under Admin, Settings, Slack | Confirm the installed app was generated from the supplied manifest and who holds its tokens |
Which recipient controls need Pro or Enterprise
On Pro and Enterprise, Metabase admins can limit email subscription recipients to approved domains. This is the main recipient control that paid plans add for dashboard subscriptions. Open Source and Starter do not include it, so on those plans nothing in Metabase stops a subscription from being sent to an address outside your organization. Before you roll out subscriptions to a team, decide whether that gap is acceptable for the data in the dashboards being sent, and record that decision with the people who own the data.
The pricing page places several other controls in the same plan tier. SSO, row and column level permissions, multi-tenant data segregation, and usage analytics and auditing are included only in Pro and Enterprise. These matter for subscriptions because a scheduled email or Slack message carries query results to people who may not have a Metabase account. Ask Metabase in writing how row and column permissions apply to the results of a subscription, and whether audit records show who created or changed a subscription and its recipients. Do not assume either behavior until you have confirmed it for your version.
Plan contents change, so confirm the exact feature list against the current Metabase pricing page before you decide. Check three things specifically: that the approved-domain setting is in the plan you intend to buy, whether it applies only to email recipients or also to other delivery paths, and whether it can be enforced for every subscription or only for some. Put the answers in your procurement file so the plan decision rests on a dated source rather than on memory of a sales conversation.
If your plan does not include approved-domain limits, add a manual review step or restrict who can create subscriptions. A manual review step means an admin checks each new subscription's recipients and dashboard before it goes live. Restricting creation means only a named group can set up subscriptions, which narrows the number of people who can send data outside the organization. Whichever you choose, write the rule down, review existing subscriptions and recipient lists on a schedule, and confirm which roles in your version of Metabase can create subscriptions.
Securing Slack and email delivery
Slack and email delivery sends Metabase results outside the application, so the controls that protect them sit in three places: the Slack App, the mail server, and the people and recipients who can receive results. The five cards below follow the order a security review usually takes. Confirm any item that depends on your Metabase plan or on the current Slack App manifest before the design is approved.
Limit the Slack App to needed channels
The Slack App that Metabase creates from its supplied manifest should only be able to post where subscriptions and alerts need to go. Before installation, ask your security team to review every permission the manifest requests, because each one defines what the app can reach in your workspace. Then list the channels that will receive results, add the app only to those channels, and record the list so new channels go through review. Confirm the manifest contents against Metabase's current Slack setup documentation before approving it.
Protect SMTP credentials and the Slack token
Email subscriptions depend on SMTP credentials, and Slack delivery depends on the token issued when the Slack App is installed. Both let Metabase send messages as your organization, so store them in your secrets management system and keep them out of shared documents and tickets. Limit admin and settings access, since those roles can view or replace delivery settings. Set a rotation schedule with a named owner, and document how to revoke the Slack token if the app is removed or an administrator leaves. Confirm with Metabase's documentation how these values are stored in the application database.
Restrict who can create subscriptions
Anyone who can create a subscription or alert decides what data leaves Metabase, which people receive it, and how often. Decide which roles may create and edit subscriptions, then confirm in Metabase's current permissions documentation that your chosen roles can do only that. Test with a standard user account to confirm it cannot add an outside recipient. Review existing subscriptions regularly for owners who have left the organization or recipients who should no longer receive results.
Limit recipients to approved email domains
On Pro and Enterprise plans, Metabase admins can limit email subscription recipients to approved domains. Without this control, a subscription can deliver results to any address, including personal inboxes and external domains. Agree the domain list with data owners and your legal or compliance contacts, configure it, and test with an address outside the list. Define who approves new domains. If you run Open Source or Starter, state in the design how recipients will be reviewed instead.
Review shared channels for sensitive data
Slack channels shared with partners, customers or other organizations can receive results built for internal teams. Before a subscription posts to a shared channel, check whether the question's columns include personal, financial or health data, and confirm that the channel membership matches the intended audience. Set a rule that alerts to shared channels use aggregated results where possible. Re-check membership on a schedule, because a channel's audience can change after the subscription is created.
Why subscriptions fail to send or post
This table lists six common reasons a Metabase dashboard subscription or alert does not reach an inbox or Slack channel, with the likely cause and the first fix for each. Work down the rows in order, because email and Slack delivery problems are usually found at the setup level before the subscription itself needs changing. Most failures trace back to a setting outside Metabase, so the fix often sits with a mail or Slack administrator.
| Failure | Likely cause | Fix |
|---|---|---|
| SMTP not configured or relay rejecting Metabase | Email settings were never saved, or the mail relay does not accept connections from the Metabase server's outbound address or its authentication and encryption settings. | Confirm email is set up under admin settings and send a test message. Ask the mail team to allow the Metabase server on the relay and match the authentication and encryption it requires. |
| Slack App not installed or not invited to the channel | The app was created from Metabase's manifest but never installed to the workspace, or the app was not added to the target channel. | Install the app from the Slack setup under admin settings and confirm the token is saved. Invite the app to each target channel in Slack, then resend the subscription. |
| Recipient blocked by the approved-domain rule | The recipient's email domain is not on the approved list, or the list changed after the subscription was created. The setting exists only on Pro and Enterprise plans. | Review the approved domains list under admin settings. Add a domain only after your security team agrees, or ask the owner to send to an approved address. |
| Recipients not receiving messages because of mail filtering | The sending address is flagged as spam, quarantined by a gateway, or sent without the sender authentication records the recipient's mail system expects. | Check spam folders and gateway logs with the mail team. Allowlist the sending address and confirm the sending domain's authentication records are aligned for it. |
| Slack channel renamed, archived or made private | The subscription points to a channel that changed name or status, or to a private channel the app is not a member of. | Open the subscription, reselect the channel, and invite the Slack app to it. Ask the channel owner to tell Metabase owners before renaming or archiving shared channels. |
| Subscription owner losing access to the underlying data | The owner's account was deactivated, moved out of a group, or lost permission to a database or collection, so the question cannot run for recipients. | Review each subscription's owner and its underlying question permissions. Reassign ownership to a current user with access, and include subscription owners in leaver reviews. |
What upgrades and migrations do to existing subscriptions
Metabase stores dashboard subscriptions, alert definitions, recipient lists and Slack configuration in its application database, so an upgrade changes the same database that holds your delivery setup. Metabase runs application database migrations automatically when a new version starts. Before you upgrade, take a backup of the application database, not only the JAR or container image. Without that backup, a failed migration leaves you with no clean way back to the previous state. Your backup should be taken while Metabase is stopped or quiesced, so that subscriptions and Slack settings are captured in a consistent state.
The upgrade documentation also asks you to reduce a cluster to a single node for major upgrades because of a migration lock, and to upgrade one release at a time when moving from versions older than 40. For subscriptions, this means scheduled sends can be paused or missed during the window in which the node is down or migrating. Ask your platform team to confirm how your deployment handles scheduled jobs during that window, and whether any alert or subscription due during the outage should be sent manually afterward. Record which subscriptions are time-sensitive, such as month-end finance reports or operational alerts, so they can be checked first after the upgrade.
Rollback has two documented routes. The recommended route is to stop Metabase and restore the pre-upgrade application database backup, then start the previous JAR or image. The second route is to run the migrate down command with the newer JAR, which reverses schema changes. Restoring the backup returns subscriptions, recipients and Slack configuration to the state they were in before the upgrade, including anything created or edited during the upgrade window, which is lost. Decide in advance which route you would use, who has authority to invoke it, and how long you can tolerate losing changes made after the backup was taken.
After every upgrade, send a test subscription to a controlled inbox and a test Slack channel, and confirm that the message renders the expected question results and reaches a recipient without a Metabase account. Check that alerts fire against a known condition. Do this before you announce that the upgrade is complete. Keep the test subscriptions in a named test dashboard so that they can be repeated for each release. Ask your Metabase administrator to confirm the Slack App still has the scopes and connection it needed before the upgrade, because the Slack setup is stored in the same database.
Plan a backup before you change mail or Slack settings, not only before upgrades. Changing the SMTP server, sender address, or the Slack App credentials can break every subscription at once, and a backup taken before the change lets you return to a known working configuration. Confirm with your mail and Slack administrators which values must stay constant, and document the current SMTP settings and Slack App details in your change record. Treat these changes as controlled changes with a named approver and a post-change test, the same way you treat the upgrade itself.
Questions buyers ask about Metabase subscriptions and alerts
Are Metabase dashboard subscriptions and alerts free on Open Source?
Yes, subscriptions are part of the platform, and Metabase lists Open Source as its free plan. Sending dashboard results by email or Slack, including to people who have no Metabase account, works once email or Slack is set up. The exception is recipient control. Limiting email subscription recipients to approved domains is listed on Metabase's pricing page as a Pro and Enterprise capability, so Open Source does not include it. Check the current plan comparison on Metabase's pricing page before you buy, because plan contents change. Your own costs will come from the mail relay, the Slack workspace, the infrastructure that runs Metabase, and the people who configure and govern the feature.
What makes a Metabase subscription project take more effort?
Three factors drive most of the effort: the mail relay, Slack approvals, and the volume of dashboards and recipients. A mail relay that Metabase can reach over SMTP, with credentials and sender rules agreed with your mail team, is often the first dependency. For Slack, Metabase creates a Slack App from a manifest it supplies, so someone with Slack workspace rights must approve the app before anything posts. Each dashboard and each recipient list adds content to review, and a larger recipient list raises the question of who should see which results. Ask any partner to price these factors separately in a written scope, and confirm your mail and Slack approval lead times before scheduling.
Can one Metabase admin set up Slack and email delivery alone?
Yes, a single admin can configure subscriptions by following Metabase's setup steps, provided they have the access and approvals needed. Setting up email needs SMTP details and admin rights in Metabase. Setting up Slack needs admin or settings access in Metabase and approval from a Slack workspace administrator. A partner adds the most value where governance and rollout matter: agreeing who may receive what, documenting which dashboards go to which channels, testing delivery before users rely on it, and training owners to manage their own subscriptions. Whether to bring in a partner depends on how many teams will use the feature and how strict your review process is.
What does our team need to provide before subscriptions go live?
Four inputs unlock most of the work: SMTP details, Slack admin approval, a test channel, and decisions on recipients. SMTP details include the relay host, port, encryption method, authentication, and the sender address your mail team approves. Slack admin approval means a workspace administrator agrees to install the Metabase Slack App. A test channel, separate from production channels, lets you confirm formatting and delivery without sending data to the wrong audience. Recipient decisions cover who may receive email and Slack messages, including external addresses and people without Metabase accounts. Write these decisions down before the build starts, because they shape the configuration and any later review.
Can Open Source Metabase limit who receives subscription emails?
On Open Source, you cannot rely on Metabase to restrict email subscription recipients to approved domains. Metabase's pricing page places that control in the Pro and Enterprise plans. If you run Open Source, you need compensating controls: a written policy on who may be added as a recipient, regular review of subscription lists, and mail-side controls such as sending restrictions or gateway rules that your mail team manages. Confirm with your mail administrators what they can enforce before you rely on them. If domain allowlisting is a firm requirement, compare the Pro and Enterprise plans against your governance needs before the design is final.
How is Slack connected to a self-hosted Metabase instance?
Metabase connects to Slack through a Slack App that you create from a manifest supplied in Metabase. Go to Admin, then Settings, then Slack, and follow the steps to create the app from the manifest. An admin or a person with settings access completes the configuration, and the Slack workspace administrator approves the app. After approval, Metabase can post subscription results to the channels you choose. Keep the app token and workspace details in your normal secrets handling, and document which channels receive which content. Confirm the current steps in Metabase's Slack setup documentation, since screens and names can change between releases.
Who can receive a subscription if they have no Metabase account?
Once email or Slack is set up, subscriptions can reach people who do not have a Metabase account. This makes the feature useful for stakeholders who only need a periodic report, but it also means data leaves Metabase's permission model once it is sent. Results sent to an inbox or channel are no longer governed by the row and column permissions that apply inside Metabase. Before you enable this, decide which dashboards may be sent outside Metabase, who approves new recipients, and whether any content is sensitive enough to exclude. A partner can help turn those decisions into a documented recipient policy that your team can enforce.
How DeployOpen scopes and delivers Metabase subscription and Slack setup
DeployOpen scopes Metabase subscriptions and alerts in writing before any work starts, covering which dashboards, recipients and channels are in scope and which plan each feature needs. We then configure Slack and email delivery in your infrastructure, test each subscription path, and document the setup for your administrators. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope names each dashboard, recipient group and channel that will receive subscriptions or alerts.
- Scope records which recipients are Metabase users and which are external, since external recipients need email or Slack set up.
- Where a feature needs Pro or Enterprise, such as domain limits on email recipients, the scope names the plan required.
How we build
- We create the Slack App from the manifest Metabase supplies under Admin, Settings, Slack, and confirm the workspace permissions.
- We configure email delivery for subscriptions and test sending from the Metabase instance inside your network.
- We set schedules, channel targets and recipient lists to match the agreed scope and your access model.
How we hand over
- Each subscription and alert path is tested with a sample dashboard, including a recipient who has no Metabase account.
- Documentation covers Slack App setup, email settings, recipient rules and which features need Pro or Enterprise.
- Administrators receive a walkthrough for adding channels, changing schedules and removing recipients.
How we support
- Retainer support can cover Metabase upgrades and changes to subscription schedules, channels and recipients.
- Before any upgrade, we back up the application database, because Metabase runs migrations automatically on start.
- Your team confirms Slack workspace and mail provider policies so subscription delivery is not blocked after changes.
