# Work your Hightouch sync failures from one on-call console

> One screen showing every Hightouch sync that failed or dropped rows, with re-run, resync and pause controls plus shift handoff notes.

- Workflow type: app
- Services: Hightouch, Slack Bot
- Categories: Operations, Engineering
- Published: 2026-08-24

## What it does

- Opens on a Needs attention board listing every sync whose latest run failed or rejected rows, showing the sync name, its source warehouse and destination, when it last ran, rows attempted versus rows rejected, and how many runs in a row have now failed, with a healthy list underneath so the whole workspace fits on one screen.
- Click any sync for a drill-down with its last twenty runs, their status, duration and row counts, plus the sync's own configuration and schedule, and act on it right there: re-run it, kick off a full resync when the destination has drifted, pause or resume it while you fix the upstream model, or fire the whole sync sequence when the failure was an ordering problem.
- Press Diagnose this failure and a background assistant reads the recent run history, the sync setup and its source and destination context, works out whether this is a temporary destination rejection, an upstream model problem or a credentials issue, then writes a plain-English root cause and recommended fix into the app as an incident note and posts the same summary to your Slack channel.
- Anyone on shift can acknowledge a sync with a note that records who looked at it and when, and repeated failures of the same sync roll up into a single incident rather than one row per failed run, so the next person on shift picks up where you left off instead of re-diagnosing the same break.

## What you'll need

- A Hightouch workspace with syncs already running, and admin access to create a workspace API key
- A Slack workspace, and the channel your data team watches during an on-call shift
- Nothing to install in your warehouse or destinations, the console reads and controls what Hightouch already knows

## Prompt

Build me a Hightouch sync operations console that my data team works out of during an on-call shift, instead of refreshing the Hightouch UI. It should be a single interactive app: a board of everything that needs attention, a drill-down per sync, controls to actually fix things, shared acknowledgement notes for shift handoff, and a background agent that diagnoses a failure and reports back.

Landing view: a "Needs attention" board. Use List Syncs to get every sync in the workspace, then List Sync Runs for each one to read its recent run history. A sync belongs on the board when its most recent run failed, or when its most recent run completed but rejected rows. Each card shows the sync name, its source warehouse and its destination (resolve those names with List Sources and List Destinations rather than showing raw ids), when it last ran, rows attempted versus rows rejected, and how many consecutive runs have now failed. Sort the board so the worst offenders sit at the top: longest failure streak first, then most rows rejected. Below the board, show a compact healthy list of every other sync with its last run time and status, so the whole workspace is visible on one screen without scrolling through a second page.

Two grouping rules matter, and both come from how Hightouch itself talks about alert fatigue. First, group repeated failures of one sync into a single incident rather than showing one row per failed run. The card is the incident: it carries the first time the sync started failing, the consecutive failure count, and the latest error, not a stack of near-identical rows. Second, treat partial row rejections differently from a hard sync failure. A hard failure means the run did not complete and a re-run is a reasonable first move. Rejected rows mean the run completed but the destination refused some records, which usually needs a data fix upstream, so label those cards distinctly (for example "Rows rejected" versus "Sync failed"), show the rejected-versus-attempted ratio prominently, and do not present re-run as the obvious action there.

Clicking a sync opens a drill-down. Show its last twenty runs from List Sync Runs, each with status, start time, duration and row counts (attempted, successful, rejected), so trends are visible at a glance: is this a sync that has always been flaky, or one that broke this morning. Alongside the run table, show the sync's own configuration and schedule from Get Sync, plus its source and destination details, so the on-call person does not have to open Hightouch to remember what this sync actually does.

From the drill-down I need to act. Give me buttons to re-run the sync (Trigger Sync Run, or Trigger Sync By ID or Slug when I only have the slug), to kick off a full resync when the destination has drifted and every source row needs re-evaluating (same trigger operation with the full resync option set, and put a confirmation step in front of it because it is expensive), to pause or resume a sync while we fix the upstream model (Update Sync, toggling the disabled state), and to fire a whole sync sequence when the failure was ordering-related (Trigger Sync Sequence). After triggering a sequence, poll Get Sync Sequence Run Status and show each step's progress in the drill-down so I can watch the sequence work through rather than guessing. Every action should show its result inline and refresh the run list, and pausing or resuming should immediately update how the sync appears on the board.

Add a "Diagnose this failure" button on each card and in each drill-down that kicks off a background agent. The agent reads that sync's recent run history with List Sync Runs, its configuration with Get Sync, and its source and destination context with List Sources and List Destinations. It works out which of three things is going on: a transient destination rejection that a re-run will clear, an upstream model or data problem where the source rows themselves are wrong, or a credentials or permissions failure on the source or destination connection. It then writes a plain-English root cause and a recommended fix back into the app as an incident note attached to that sync, so it appears in the drill-down and is flagged on the board card, and posts the same summary to a Slack channel using Send a Message. The Slack post should name the sync, the destination, the failure streak, the verdict and the recommended next step, and it should be readable by someone glancing at their phone. The agent never triggers, pauses or changes a sync itself: it only reads, writes the note and posts to Slack. A human presses the fix buttons.

Bake in shift-handoff behavior. Any sync can be acknowledged with a free-text note, and the app stores that note along with who acknowledged it and when. Acknowledged syncs stay on the board but visibly settle down (muted styling, an "Acked by" line with the person and timestamp, and the note itself readable without opening the drill-down) so the next person on shift sees what was already investigated and does not re-diagnose the same failure. Notes and acknowledgements persist in the app across sessions and are shared across everyone using it, and they are keyed to the sync so a fresh failure of an already-acknowledged sync surfaces the earlier note as history rather than hiding the new break. Let someone clear an acknowledgement when the incident is genuinely resolved, and keep resolved incidents readable for a while so the shift handoff has context.

Keep the whole thing fast and legible under pressure: the board is what someone stares at for an hour, so lead with sync name, destination and the failure streak, use color only to distinguish hard failures from row rejections from healthy, and give me a manual refresh so I can pull fresh run data after triggering something.

## How to customize

- Decide what counts as needing attention: any rejected row at all, or only once rejections pass a share of the rows attempted
- Change how many recent runs the drill-down shows and how far back consecutive failures are counted before something is called an incident
- Point diagnosis summaries at a different Slack channel, or keep them as in-app notes only

## FAQ

### Does this replace the Hightouch interface?

It replaces the part you live in during an on-call shift. Instead of clicking through syncs one at a time to see what broke, you get every failing sync on one board with the run history, the configuration and the fix buttons in the same place. Everything you press still happens in Hightouch, so the two stay in step.

### What is the difference between a re-run and a full resync?

A re-run processes the same work the sync would normally do next. A full resync re-evaluates every row in the source and sends it all again, which takes longer and moves far more rows. The console keeps them as two separate buttons so nobody triggers a full resync by accident when a plain re-run would have done.

### Why are rejected rows treated differently from a failed sync?

A sync that fails outright usually needs another attempt. A sync that finished but rejected some rows usually has a data problem, like a missing required field or a value the destination will not accept, and re-running it just rejects the same rows again. The board separates the two so you spend re-runs where they actually help.

### Can the whole team use it during the same shift?

Yes. Acknowledgements and incident notes are shared, and each one shows who added it and when, so two people are not quietly investigating the same failure and the person taking over the shift can see what was already tried.

### Does the diagnosis button change anything in my syncs?

No. The assistant only reads the run history, the sync setup and the connected source and destination, then writes back a written explanation and a suggested fix. Re-running, resyncing and pausing stay manual actions that a person chooses to take.

Use this prompt in General Input: https://www.generalinput.com/prompts/work-your-hightouch-sync-failures-from-one-on-call-console