Notification Center (Early Access)

When configured and enabled, the Notification Center delivers fault notifications when a supported input or output configuration encounters a critical error that prevents data from being ingested or forwarded through your mParticle account.

By surfacing these critical errors in real-time or near-real-time, fault notifications can lead to faster issue resolution and a more reliable and trustworthy customer data infrastructure.

Notification types

During the Early Access, the Notification Center supports the following notification types:

• Fault Notifications: critical notifications delivered when a supported integration fails to process data, either during ingestion (input) or forwarding (output).

Notifications can be delivered to both individual destinations and shared destinations:

• Individual destinations (managed by each user in your account)

  • In-app
  • Email

• Shared destinations (managed by Admin & Compliance users)

  • Email list
  • Slack
  • Custom webhook

Input faults

Input fault notifications are triggered when mParticle fails to ingest data from a supported Warehouse Sync input due to a pipeline configuration or connection issue.

Warehouse Sync inputs

Supported warehouse sync integrations:

• Amazon Redshift
• Databricks
• Google BigQuery
• Snowflake

Output faults

Output fault notifications are triggered when mParticle fails to forward data to a configured output destination. These faults may involve connectivity issues, misconfigurations, or errors returned by downstream systems.

Warehouse outputs

Supported data warehouse output integrations:

• Amazon Redshift
• Google BigQuery
• Snowflake

Audience outputs

Fault notifications are sent when downstream partners return non-retryable errors to mParticle that require action from you to resolve. (For all other errors, mParticle continues retrying to forward data in the background.)

Supported audience output integrations:

• Aarki
• AB Tasty
• AdColony
• Adobe Audience Manager
• Adobe Target
• Airship
• Amazon Advertising
• Amazon Kinesis Firehose
• Amazon S3
• Amobee
• Apache Kafka
• Audience Webhook
• Braze
• Corial
• CrossInstall
• Databricks
• Dynalyst
• Emarsys
• Facebook
• Foursquare
• Google Ads
• Google BigQuery
• Google Enhanced Conversions
• Google Marketing Platform
• Google Marketing Platform Offline Conversions
• Hyperlocology
• Iterable
• Jampp
• Klarna
• Klaviyo
• Leanplum
• MadHive
• Microsoft Azure Blob Storage
• MoEngage
• myTarget (Mail.ru Group)
• Narrative
• Optimizely
• Oracle Responsys
• Pinterest
• Reddit
• Rokt
• Salesforce Email
• SendGrid
• Slack
• Snapchat
• Sprig
• StartApp
• Talon.One
• TikTok Audience
• Twitter
• Voucherify
• Yahoo
• YouAppi

Manage your personal notification preferences

mParticle allows individual users to manage how they receive notifications by customizing their personal preferences. You can choose to receive in-app alerts, email notifications, or both for each supported notification type. This ensures you stay informed about critical events in the way that works best for you.

To access your personal notification preferences:

1. Log in to your mParticle account.
2. Hover your cursor over the Settings gear icon in the left-hand navigation, and select My Profile.
3. Select the Notifications Preferences tab.

Notification preferences are grouped by notification type. To subscribe to a specific notification type, check the box under In-App or Email next to the notification type you want to receive. To unsubscribe from all notifications for a particular type, uncheck the boxes under both In-App and Email.

In-app notifications

In-app notifications can be found via the notifications bell icon in the bottom of the left hand navigation. A red dot indicates new, unread notifications.

Click the bell icon to view your in-app notifications.

Each in-app notification lists the input or output configuration that faulted, a technical error message describing why the fault occurred, and a link to the configuration’s settings within the mParticle UI.

You can click the settings cog icon from the in-app notifications panel to go to your notifications preferences.

Manage shared destinations (Admin & Compliance only)

In addition to managing personal notification preferences, mParticle Admin and Compliance users can configure shared notification destinations to ensure critical information reaches the right teams and channels. These shared destinations (like team email lists, Slack channels, or webhook endpoints) help you to increase broader visibility across your organization. By setting up shared notifications, Admin users can streamline incident response, improve cross-functional awareness, and ensure that fault alerts are not siloed to individual users.

To find your shared notification preferences:

1. Log in to your mParticle account.
2. Hover your cursor over the Settings gear icon in the left-hand navigation, select Platform, and go to the Notifications tab.

This page is where you can control workspace-level notification settings for each configured destination. Each row represents a notification type, and each column represents a shared destination (such as an email list or Slack webhook). To enable or disable a specific notification type for a destination, simply check or uncheck the corresponding box in the grid.

Add a new destination

Email List

Email lists are shared notification channels that allow Admins to send fault notifications to a group of email recipients. Unlike personal email notifications, which are managed individually, email lists ensure that critical alerts are delivered to multiple stakeholders (like data engineering teams or system admins) through a centralized distribution list.

To add a new email list:

1. Click the + Add destination button and select the destination you want to configure (either Email List, Slack, or Webhook).
2. Enter a descriptive name for your email list destination. For example, if you want these notifications to be delivered to the email addresses of your account administrators, use “Account Admins”.
3. Enter each email address you want to receive notifications. Separate multiple addresses with a comma.
4. Click Save.

Slack

Before you can add a Slack destination, you need to create an Incoming Webhook in your Slack workspace:

1. Create a Slack App

1. Visit the Slack App Directory.
2. Click Create New App.

3. In the modal that appears:

   • Select From scratch
   • Enter an app name (e.g., mParticle Notifications)
   • Choose the Slack workspace you want to use
   • Click Create App

2. Enable Incoming Webhooks

1. In the left-hand sidebar, select Incoming Webhooks.
2. Toggle the switch to Activate Incoming Webhooks.
3. Scroll down and click Add New Webhook to Workspace.
4. Select the Slack channel where you want to post notifications (e.g., #warehouse-input-notifications).
5. Click Allow to authorize.
6. After authorization, a Webhook URL will be generated for your selected channel.

7. Copy the URL — it will look something like:

   https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

3. Create your Slack notification destination in mParticle

1. From your Notifications Platform Settings page, click + Add destination and choose Slack.
2. Enter a name for your Slack destination (e.g., #data-alerts - Fault Notifications).
3. Paste the Webhook URL from Slack in Slack Webhook URL.
4. Click Save.

Webhook

For advanced use cases, mParticle supports custom webhook destinations that receive fault notifications as raw, JSON-formatted payloads. This allows you to integrate notifications directly into your internal systems, such as monitoring tools, incident response workflows, or observability pipelines. Each notification includes structured metadata about the faulted configuration, making it easy to programmatically parse, log, or trigger automated responses.

To create a custom webhook destination:

1. Ensure you have a working webhook endpoint that can receive POST requests containing JSON payloads.
2. From your Notifications Platform Settings page, click + Add destination and choose Webhook.
3. Enter a name for your webhook destination.
4. Under Webhook URL, enter the URL for your custom webhook.
5. If your webhook requires authorization to receive POST requests, enter the key under Authorization.
6. Click Save.

Example webhook notification payloads

All raw, JSON-formatted notifications will include some common fields, such as your account ID, the timestamp when the fault was detected, and an error message. See the table below for a complete reference of these common fields included with each notification:

Each notification type will include additional descriptive fields that are specific to the particular entity (e.g. a Warehouse pipeline or an audience output) that faulted. Following are examples of JSON-formatted notifications for each notification type, along with a descriptive list of the entity-specific fields included.

Example warehouse input notification payload

{
  "account_id": "4732",
  "account_name": "NimbusRetail_Main",
  "detected_at": "2025-07-08T14:37:52.421Z",
  "error_message": "An unhandled error has occurred.",
  "org_id": "8921",
  "org_name": "Nimbus Retail Inc.",
  "pipeline_id": "redshift__k4lm9",
  "pipeline_name": "Redshift Pipeline",
  "pipeline_status": "faulted",
  "pipeline_url": "direct URL to the pipeline configuration",
  "workspace_id": "25",
  "workspace_name": "US Marketing Prod"
}

Specific Warehouse input notification fields

Example warehouse output fault notification JSON

All warehouse output fault notifications sent to custom webhooks match the following format:

{
  "account_id": "4732",
  "account_name": "NimbusRetail_Main",
  "detected_at": "2025-07-08T19:04:44.035Z",
  "error_message": "The maximum number of attempts has been reached in ExternalSnowflake loader for [OutputConfigurationId 56164] [StreamPartition 0]",
  "org_id": "8921",
  "org_name": "Nimbus Retail Inc.",
  "warehouse_output_id": "540",
  "warehouse_output_name": "Snowflake Warehouse Output",
  "warehouse_output_url": "direct URL to the output configuration",
  "workspace_id": "25",
  "workspace_name": "US Marketing Prod"
}

Specific Warehouse output notification fields

Example audience output fault notification JSON

All audience output fault notifications sent to custom webhooks match the following format:

{
  "account_id": "4732",
  "account_name": "NimbusRetail_Main",
  "audience_output_id": "1051",
  "audience_output_name": "Audience Output",
  "audience_output_url": "direct URL to the output configuration",
  "detected_at": "2025-07-08T19:03:13.126Z",
  "error_message": "Audience forwarding failed: Received HTTP 403 Forbidden - Invalid or expired OAuth token. Please re-authenticate the destination account to resume delivery.",
  "org_id": "8921",
  "org_name": "Nimbus Retail Inc.",
  "workspace_id": "25",
  "workspace_name": "US Marketing Prod"
}

Specific Warehouse output notification fields

Delete a destination

To delete a destination:

1. Navigate to Notifications under Settings > Platform.
2. Hover your cursor over the destination name and click Edit.
3. Click Delete. When the confirmation modal appears, click Delete.

Testing notifications

To validate your notification configuration, set up a working destination (e.g., a verified email), then intentionally trigger a fault. One way to do this is to:

• Modify credentials or settings for a partner integration in mParticle so that the connection fails.
• This approach ensures mParticle detects a real, reproducible fault.

Notification duplication

Due to the distributed nature of mParticle’s architecture, the same fault may be detected by multiple systems—particularly in Audience outputs. This may result in duplicate fault notifications for a single issue.

We’re actively working on improving deduplication ahead of General Availability (GA). In the meantime, please report excessive duplication to our support team.

mParticle prioritizes over-communication to ensure no fault goes unnoticed.

When notifications are triggered

Notifications are triggered at the point mParticle detects a non-retryable fault in a configuration. When faults are detected varies depending on the specific input or output integration.