A sync alert fires when a sync enters a warning or critical state, and sends a notification to the people or channels you choose.
| Audience | Data teams and admins monitoring sync health |
| Prerequisites | At least one sync. |
Configure alerts once per destination, override them on the syncs that need it, add the recipients who should hear about them, then let Hightouch notify you when a sync breaks or degrades.
How alerting works
Each sync is evaluated against a set of triggers that watch for problems like failed runs, rejected rows, slow performance, or unexpected data drops. Two terms do the work:
- Alert — the signal that a sync has entered a
WARNINGorCRITICALstate, based on a trigger crossing its threshold. - Notification — the message a recipient receives. Alerts always show in the Hightouch app; a notification only goes out if a recipient is subscribed at that severity.
Instead of showing only the last run's result, each sync shows a rollup of its current alerting state: No alerts when everything is healthy, or the number of active alerts when one or more triggers are in a WARNING or CRITICAL state. This reflects whether the sync is healthy, degraded, or needs attention, regardless of when it last ran.
When notifications are sent
Hightouch sends one notification per trigger status change, not per run, so a persistent problem doesn't notify you on every run. For example:
- A sync rejects rows and crosses the warning threshold. You receive one
WARNINGnotification. - It keeps rejecting rows on later runs. No new notification.
- Rejections climb past the critical threshold. You receive one
CRITICALnotification. - The sync recovers. You receive one recovery notification.
Configure alerts
Set alert triggers at two levels. Destination-level settings apply to every sync using that destination; sync-level settings override them for a single sync.
To set destination-wide defaults, go to Integrations > Alerting, open the Syncs tab, and select a destination. Set its triggers and recipients, and every sync using that destination inherits them.
To override the defaults for one sync, open the sync and click the Alerting tab. A sync inherits its destination's defaults; adjust its triggers or recipients here to override them.
Changes take effect the next time thresholds are evaluated: after the next sync run, or about every five minutes for time-based triggers.
Trigger types
Fatal errors, Rejected rows, and Sync throughput come preconfigured with defaults. Model or audience size and Sync duration start off until you configure them.
| Trigger | What it watches | Default |
|---|---|---|
| Fatal errors | Runs that can't complete because of an infrastructure or configuration problem, such as unreachable credentials or invalid SQL. | CRITICAL if any run has a fatal error. |
| Rejected rows | Rows the destination rejected because of schema mismatches, validation failures, or destination constraints. | WARNING if any rows are rejected during a run. |
| Sync throughput | Successful operations over a time window, to catch stalled or idle syncs. | WARNING if no successful operations occur in seven days. |
| Model or audience size | The number of rows the model returns at run time, which can flag broken upstream filters or joins. | Off until you set a minimum row count. |
| Sync duration | Wall-clock runtime, from when a run is queued to when it finishes. | Off until you set a duration threshold. |
Fatal-error and rejected-row triggers are evaluated right after each run ends. Time-based triggers — throughput and duration — are evaluated about every five minutes, so they can fire before a long-running run finishes. To adjust a trigger, click the pencil icon on it.
Set up recipients and channels
Recipients are the people and channels that receive notifications. Manage them on the Recipients tab of Integrations > Alerting, where each channel type is set up once:
- Email — add an address directly.
- Slack — authorize the Slack connection, then choose a channel.
- PagerDuty — complete the PagerDuty setup, then route alerts to a service.
- SMS — add a phone number. Hightouch covers the cost of SMS alerts.
- Webhook — send a JSON payload to a URL you specify. See Send alerts to a webhook.
For each recipient, choose how much to send under Alert severity:
- Send all alerts — notify on both
WARNINGandCRITICALstatus changes. - Send critical alerts only — notify on
CRITICALstatus changes only.
You can also scope a recipient to specific destinations, and still override that routing per sync from the sync's Alerting tab.
Test a recipient
Before you rely on a recipient, confirm it works. On the recipient's settings, click Send a test alert now to send a test notification through that channel.
Send alerts to a webhook
A webhook channel delivers a JSON payload to a URL you specify whenever an alert fires or recovers. Webhook channels support custom HTTP headers, sent with every request, for authentication tokens or routing keys your endpoint requires — for example Authorization: Bearer <token> or X-Routing-Key: ops-team.
Mute a trigger
Mute a trigger to stop its notifications during planned maintenance, a known issue, or quiet hours. A muted trigger still updates the sync's alert state and appears in rollups; it just doesn't notify anyone.
From the sync's Alerting tab, click the volume icon on the trigger and select a mute duration — a fixed window such as one hour or one day, or indefinitely. You can also mute from the Mute... link at the top of an active alert on the sync page.