Monitoring and freshness
Check schedule delivery, successful completion and the actual business output
Pipeline monitoring answers three separate questions: did the intended occurrence create work, did the run finish successfully, and does its output contain the data you expected? A healthy schedule or a recent completion alone cannot answer all three.
You need a Semogram account with access to the project and run history. Workspace administrators manage schedules and recovery. External destination inspection also requires access to that system.
Inspect Operations
Open the pipeline's Operations page. It shows schedules, upcoming execution, errors, occurrence history, recent runs and the last fully successful completion. Inspect the same pipeline/version and run rather than comparing unrelated records.
| Signal | Meaning | Follow-up |
|---|---|---|
| Enabled and next run | The schedule is eligible for future consideration | Verify scheduler availability and time zone |
| Occurrence skipped | Overlap or missed-time policy prevented a launch | Read the occurrence outcome and active runs |
| Schedule error | Preparation or authorization failed | Inspect actor access and the saved pipeline |
| Run queued | Work is accepted, possibly awaiting dispatch | Inspect the retained run; avoid duplicate launches |
| Run partial/failed | Some work may already have completed | Read node results and destination state |
| Last successful completion | Most recent fully successful pipeline finish | Compare it with expected cadence and source timestamps |
The completion freshness timestamp is not source-data age. A run today could copy records last updated last month. Failed and partial runs do not advance the fully successful completion timestamp. No configurable freshness SLA or automatic alert delivery is implied by this display.
Example daily check
For a weekday 09:00 Europe/Berlin order refresh, inspect the day's occurrence and linked run after the deployment's scheduler has had time to check it. If overlap caused a skip, inspect the older active run rather than creating another concurrent write.
For the linked run, compare source and output order IDs, row counts, expected transformations and source update timestamps. A filter can legitimately reduce counts; a join can multiply rows. Document the expected relationship before treating a difference as an error.
If the latest run is Failed but last success is yesterday, inspect whether it wrote some new rows. The destination may contain mixed-age output even though the freshness timestamp still points to yesterday.
Read through supported interfaces
Use Operations for schedule/run history and open a run for node errors, durations and artifacts. Follow output records to verify business values.
Inspect this order-refresh pipeline's recent runs. Report the exact IDs and versions, the last fully successful completion, any queued/running work and the first failed node. Distinguish completion time from source-data age and flag missing evidence rather than guessing that output is current.A connected assistant can read exposed tools. The aggregate Operations UI is not itself a public MCP method.
Read a known run with an API key granted runs:read and access to its project:
curl "https://platform.semogram.com/api/v1/projects/<PROJECT_ID_UUID>/runs/<RUN_ID_UUID>" \
--header "Authorization: Bearer ${SEMOGRAM_API_KEY}"Replace IDs with the accepted run's IDs. This route does not provide schedule management or the entire Operations screen.
Through an initialized workspace MCP connection, call job_get with projectId and jobId equal to the pipeline run UUID. Use pipeline_schedule_list / pipeline_schedule_get for schedule state. On a project-scoped connection omit the already-bound projectId. Inspect returned completeness/warnings along with data.
When monitoring finds a problem
Pause future schedule selection if it would repeat unsafe work. Pausing does not stop an already queued run. Review active work separately, preserve IDs and receipts, then use checkpoint recovery or a validated new version as appropriate. Do not delete the failed run to make the history appear healthy.