# See every Census sync's health and fix it in one place

> Open one board every morning to see which Census syncs failed, read the real error, and retry, pause, or flag them without leaving the page.

- Workflow type: app
- Services: Census, Slack Bot
- Categories: Engineering, Operations
- Published: 2026-08-16

## What it does

- Lists every sync in your Census workspace with its latest result, source, destination, schedule, and how many records went through or were rejected.
- Filters by source, destination, and status, with a failing-only toggle so a bad morning takes one click to scope.
- Opens any sync to show its setup plus a run-by-run history, including the exact error text behind each failed run and whether the destination connection itself is broken.
- Lets you retry, pause, or resume a sync right there, and post a short incident note to your data ops Slack channel.

## What you'll need

- A Census workspace (now branded Fivetran Activations) and permission to create a workspace API key
- A Slack workspace where a bot can post, plus the channel your data ops team watches
- Your syncs, sources, and destinations already set up in Census

## Prompt

Build me a Census sync control room: an internal app I open every morning to see the health of every sync in my Census workspace and actually fix things, instead of clicking through the Census UI one sync at a time. Census is a reverse ETL platform now branded Fivetran Activations, and the app talks to it with a workspace-scoped API key.

The main view is a board listing every sync in the workspace. Load them with List Syncs, following pagination (page is 1-indexed, per_page maxes out at 100) until pagination.next_page is null, and enrich each sync with its most recent run from List Sync Runs. Each row shows the sync name, whether it is active or paused, the status of the latest run, the source, the destination, the schedule, when the last run finished, records synced, and records rejected. Resolve the integer source_id and destination_id into readable connection names using List Sources and List Destinations, and cache those two lookups for the session instead of refetching them per row. Call out rows whose latest run failed, and also rows with a non-zero rejected-record count even when the run itself came back successful.

Above the board give me filters by destination, by source, and by latest run status, plus a failing-only toggle that narrows the board to syncs whose most recent run failed. Add a refresh control with a last-refreshed timestamp, and a small summary strip across the top: total syncs, how many are failing, how many are paused, and total records rejected across the latest runs.

Because a whole destination can be broken rather than one sync, surface destination health too. Use Fetch Destination to read the last connection test result for each destination that appears on the board, and badge the destination both in the row and in a compact destinations panel when its connection test is failing. That is what lets me tell a broken credential apart from a bad field mapping at a glance.

Clicking a sync opens a detail panel. Show its full configuration from Fetch Sync: source object, destination object, sync behavior, schedule, paused state, and field mappings. Below that, a run history timeline from List Sync Runs with each recent run's status, start and finish time, records synced, records updated, and records rejected. For failed runs, show error_code, error_message, and error_detail exactly as Census returns them, since run-level failures never come back as HTTP errors and that text is the only real diagnosis.

From the detail panel I can retry the sync. Bake in that triggering is not succeeding: Trigger Sync Run returns 200 as soon as the run is queued, so never report success off the trigger call. Take the returned sync_run_id and poll Fetch Sync Run on an interval of a few seconds, backing off as it goes, while the UI shows a live running state, then display the real outcome: completed with record counts, or failed with the error code, message, and detail. If polling passes a sensible ceiling, say the run is still in progress and let me check again rather than claiming it finished.

Disable the retry button whenever a run is already in flight for that sync, whether this app started it or the board shows the latest run as queued or working, so nobody stacks duplicate runs. Census explicitly warns that repeatedly triggering the same sync mid-run is wasteful, so deduplicate trigger calls in the app: one in-flight run per sync, and the button stays disabled until polling settles.

I also want to pause and resume a sync from the panel using Update Sync. Census patches top-level fields only and does not deep-merge nested objects, so if an update touches mappings, schedule, or source and destination attributes, send those objects in full. After the update, refresh that sync's row so the board reflects the new paused state immediately.

Finally, let me post a short incident note about the sync to our data ops Slack channel with the Slack bot's Send a Message action. Pre-fill the note with the sync name, source, destination, latest run status, and the error code and message when the last run failed, and let me edit the text before it sends. Let me pick the channel with List Channels, remember the chosen data ops channel as an app setting, and keep a small log of notes posted from the app so the detail panel shows what was already reported and when.

Census mechanics to respect throughout: every response is wrapped as { status, data, pagination }, so always read from data; sync_id, source_id, destination_id, and sync_run_id are all integers; a 429 comes back with a Retry-After header, so back off for that many seconds and retry instead of blanking the view. Because the board fans out one List Sync Runs call per sync, fetch those with bounded concurrency and cache results between refreshes. Handlers run server-side with the workspace API key, and when a call fails, show me what broke in the UI rather than rendering an empty board.

## How to customize

- Choose which Slack channel incident notes go to and reword the note template your team posts.
- Set the board's default view, for example open straight into failing syncs only.
- Change how far back the run history goes and how many runs each sync timeline shows.

## FAQ

### When I hit retry, does it really confirm the sync worked?

Yes. Census confirms only that a run was queued, not that it succeeded, so the app keeps watching the run until it finishes and then shows the real outcome, including the error text if it failed.

### Can two people accidentally retry the same sync at once?

No. The retry button is disabled while a run is already in flight for that sync, so nobody stacks duplicate runs on top of each other.

### Will this change my sync settings?

Only when you ask it to. The board is read-only apart from three deliberate actions: starting a run, pausing a sync, and resuming a sync.

### Can I tell a broken credential from a bad field mapping?

Yes. The app shows the last connection test for each destination, so a whole destination failing its test looks different from a single sync rejecting records.

### Does this still work now that Census is part of Fivetran?

Yes. Census is branded Fivetran Activations, and it still uses its own workspace API key, which is what you connect here.

Use this prompt in General Input: https://www.generalinput.com/prompts/see-every-census-syncs-health-and-fix-it-in-one-place