6. Watch and health

Watch is the last step of the sequence. Every system and every flow has its own Watch: runs, failed writes, repairs, health and alerts. Review holds the workspace-wide views, Health and alerts and Repairs.

Start with the overview

For any broad question ("what needs attention?"), start here:

curl "https://api.inferrex.com/v1/workspace/overview?detail=brief" \
  -H "X-API-Key: $INFERREX_API_KEY"

It returns a summary and recommendations for each area you can see, worst first. Each recommendation has a severity (critical, warning, info), a kind (problem, decision, improvement), a plain title and reason, the records it concerns, and a link to the page in the app where it is fixed. Ask for one area in full with module=<key>. It only reads.

MCP tool workspace_get_environment_overview.

Health

To see this	Call	MCP tool
A health score for each system over the last day	`GET /v1/monitoring/health`	`monitoring_get_connection_health`
A workspace summary of syncs, errors and alerts over the last day	`GET /v1/monitoring/summary`	`monitoring_getsummary`
Flows with failed writes or repairs waiting	`GET /v1/pipelines/attention`	`pipelines_get_pipeline_attention`
What happened, as events	`GET /v1/pipeline-events`	`monitoring_pipeline_events_list`

Shape of one system's health:

{
  connection_id: string;
  display_name: string;
  score: number;
  unmeasured: boolean;
  factors: { error_rate: number; latency: number; volume_consistency: number; uptime: number; inference_mode_switches: number };
  trend: string;
  computed_at: string;
}

unmeasured: true means the system had no events in the last day, so there is nothing to score. Show it as no activity, not as a score of zero.

Filter events with connection_id, pipeline_id, severity or event_type.

Runs

GET /v1/pipelines/:id/history returns a flow's recent syncs, newest first: when each ran, how long it took, and how many records were read, written, skipped or failed.

GET /v1/jobs lists recent background jobs for the workspace. GET /v1/jobs/:id reads one. A job's error says why it failed.

Failed writes

A failed write is a record a flow could not write to its destination. In the API it is a quarantine row.

curl "https://api.inferrex.com/v1/pipelines/PIPELINE_ID/quarantine?status=open" \
  -H "X-API-Key: $INFERREX_API_KEY"

GET /v1/quarantine lists failed writes across every flow, with filters for pipeline_id, connection_id, status and entity_type.

Each row carries the failure_reason the destination gave and a retry_count.

Most failed writes need nothing from you. The next sync tries each one again, and it leaves the list once it is written.
A record whose reason starts record_validation: has no value for a field the destination requires. It is not tried again until it changes. Correct it in the source system.
POST /v1/pipelines/:id/quarantine/:quarantineId/release sends one held record once more, as it is now.

Repairs

A repair is a problem Inferrex found and fixed, or one it needs your help with. In the API a repair is a heal.

curl "https://api.inferrex.com/v1/heals?status=open" \
  -H "X-API-Key: $INFERREX_API_KEY"

Narrow the list with status (open or resolved), pipeline_id (one flow) or connection_id (one system). Page with cursor, passing the nextCursor from the previous page.

A repair that needs you carries a question and suggested options. Answer it:

curl -X POST https://api.inferrex.com/v1/heals/HEAL_ID/answer \
  -H "X-API-Key: $INFERREX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"answer": "ONE_OF_THE_OPTIONS_OR_YOUR_OWN_WORDS"}'

The answer is recorded and Inferrex carries on with it. Sending the same answer again is safe.

Safety stops

A safety stop holds a sync that looks wrong, so bad data does not spread. In the API a safety stop is a circuit breaker.

List them with GET /v1/circuit-breakers. See the records a stop is holding with GET /v1/circuit-breakers/:id/records.

Decide a stop:

Decision	Call	Effect
Approve	`POST /v1/circuit-breakers/:id/approve`	You checked the sync and are happy for it to carry on. The system goes back to syncing normally.
Let some through	`POST /v1/circuit-breakers/:id/partial-approve` with `approved_record_ids`	Only the records you choose are written. The rest are dropped from the release.
Reject	`POST /v1/circuit-breakers/:id/reject`	The held data is deleted and the stop closes.
Keep stopped	`POST /v1/circuit-breakers/:id/hold-open`	Nothing syncs on the system until you approve, reject or close the stop.
Force close	`POST /v1/circuit-breakers/:id/force-close`	The stop closes straight away, whatever state it is in.

Reject deletes the held data. Read the held records before you choose it.

Rules for when a stop trips live at /v1/circuit-breaker-policies. A rule's action is warn, pause or pause_and_quarantine.

GET /v1/pipelines/:id/anomalies lists unusual data spotted in a flow's records, such as values of the wrong type, fields that are suddenly empty, or a sudden change in how often records arrive.

To see this	Call	MCP tool
Secrets your systems are refusing right now	`GET /v1/workspace/secrets/failing`	`credentials_list_failing_secrets`
Whether a provider sign-in keeps renewing, and when it would lapse	`GET /v1/connections/:id/sign-in-status`	`credentials_get_connection_sign_in_status`
Whether a system's saved sign-in still reads data	`POST /v1/connections/:id/test`	`connections_test_saved_connection`

Alerts

An alert rule says which events send an alert, and where.

Add a channel: POST /v1/workspace/notification-channels. A channel's kind is email, sms or webhook. Save its secret with POST /v1/workspace/notification-channels/:id/credential and check it with .../verify.
Add a rule: POST /v1/alert-rules, naming the events and severities it matches and the channels it notifies.
Send a test: POST /v1/alert-rules/:id/test. Test alerts are marked as tests.
See what was sent: GET /v1/alert-deliveries.
When a rule fires and someone is on it: POST /v1/alert-rules/:id/acknowledge.

In the app these are at Workspace settings: Notification channels and Alert rules.

To have your own software told when things change, use outbound webhooks (chapter 8).

Reports

A report only reads. It never changes a record. In the app, Reports covers Golden record quality, sync and flow health, destination delivery and duplicate systems, and each table can be exported as CSV. Stack insights and Sensitive data are listed there too.

From the API there is one read-only query:

curl -X POST https://api.inferrex.com/v1/reports/query \
  -H "X-API-Key: $INFERREX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"parts": [{"dataset": "sync_runs"}], "groupBy": ["day"]}'

parts names the datasets to read: sync_runs, destination_dispatches, golden_destination_sends, golden_quality, golden_source_share or golden_proposals. Each part can name its measures and filters. groupBy names the dimensions. from and to bound the days. Each dataset in the answer reports asOf, when its summary was last refreshed for your workspace.

A diagnosis order that works

When a flow or system is failing, check in this order:

GET /v1/workspace/overview?detail=brief for the worst items first.
GET /v1/pipelines/:id for the flow's status, and GET /v1/pipelines/:id/history for its last runs.
GET /v1/jobs/:id for the error of the failed run.
POST /v1/connections/:id/test on the source and each destination. A failed sign-in explains most sudden failures.
GET /v1/heals?status=open&pipeline_id=... for a question waiting for an answer.
GET /v1/pipelines/:id/quarantine?status=open for failed writes and their reasons.
GET /v1/circuit-breakers filtered by connection_id for a safety stop holding the sync.

Read first. Change nothing until you know which of these it is.

Next: environments and promotion.