# Monitor APIs and runs

Use workspace activity to investigate execution, then use the response summary to decide whether the returned data meets your requirements. A successful HTTP response and a nonempty result do not establish complete source coverage.

## Start with the recorded run

Open a run from recent request logs or the API's Runs panel. Run details show the source, definition version, outcome, available timing, record count, and retained request context. Charged Units and a charge receipt appear when authoritative billing information is available.

Use **Copy run link** to share the investigation with a teammate. The link identifies a run; the recipient must sign in and have access to its workspace. If another workspace is selected, choose the correct workspace, return to the link, and refresh. Opening or refreshing a run reads existing information without starting a new execution.

If results are available, inspect the response and download its JSON when needed. The on-screen preview may be shortened. **Results expired**, **Results were not retained**, and temporarily unavailable results describe different conditions; none means the run returned zero records. Older runs may also lack saved inputs or detailed failure context.

## Read the signals together

| Signal | What it tells you |
| --- | --- |
| Run outcome | Whether recorded execution succeeded, was partial, failed, was cancelled, or remains unknown. |
| Execution summary | Whether the selected collection scope passed and which limits or incomplete work affected it. |
| Record count | The output recorded for this run, not the size of the entire source. |
| Charged Units | Authoritative usage when available; an unavailable value is not zero. |
| Source status | Current published source information, which does not replace inspection of your request. |

Review `summary.status`, `summary.within_scope_passed`, and `catalog_complete` where provided. Check selected and completed detail counts before assuming every record received enrichment. See [pagination and output](/docs/pagination/).

## Retain execution identifiers

For server integrations, save `delivery.runId`, `delivery.chargeReceiptId`, and `traceId` when returned. Keep `summary.definition_version` with the batch so you can connect output to its definition.

The retained-result endpoint, `GET /v1/sources/{source_id}/runs/{run_id}/result`, reads an existing delivery and requires the credential's `results` scope plus source access. Retrieving a result does not start another collection. See [run an API](/docs/run-api/) for the request contract and [idempotency](/docs/idempotency/) for recovery when an execution response is lost.

## Review workspace notifications

The notification bell groups issues with links to the relevant run, schema, credential, or invitation. Failed runs group by API. Schema notifications compare saved contracts after an initial baseline is established. Credential alerts identify keys approaching expiry.

Opening notifications marks the loaded items read. Resolving an issue is a separate action, and a new failure can reopen its group. These states belong to your signed-in user.

Read any coverage or truncation notice. Notifications inspect bounded history, and a list without alerts does not prove that every API or run was checked. Email delivery depends on workspace configuration; use the delivery settings to confirm availability before relying on it.

## Add application checks

Keep the source identifier, version, run identifier, timestamp, selected limits, and summary with each downstream batch. Alert on missing required fields, unexpected result volume, partial output, and data older than your workflow permits.

Dashboard charts describe loaded history; headline totals may cover more runs. Define your own freshness and completeness requirements, then use [troubleshooting](/docs/troubleshooting/) to investigate deviations and [support](/docs/support/) to escalate a specific run.