[Daniel08886]

Overview

This PR adds a synthetic journey monitor for Utix's most valuable end-to-end workflow. It runs the critical happy path on a schedule (or on demand), records per-step latency, surfaces failures with dependency blame, and documents the operational edge cases and recovery steps needed to run it safely.

Related Issue

Changes

🩺 Synthetic Journey Monitor

• [ADD] core/health/synthetic.ts

  • Defines the critical happy-path journey as an ordered set of steps, each tagged with the dependency it exercises.
  • Executes the journey, capturing per-step latency and overall pass/fail.
  • Attributes failures to the responsible dependency so blame is reported alongside the failure.

• [MODIFY] core/health/types.ts

  • Adds the types describing journey steps, per-step results, latency samples, and dependency-blame outcomes used by the monitor.

• [MODIFY] core/health/monitor.ts

  • Wires the synthetic journey into the existing health monitor so it can be scheduled or invoked as a runnable check, and reports latency, failures, and dependency blame through the existing health surface.

• [ADD] .github/workflows/synthetic-monitor.yml

  • Scheduled (and manually dispatchable) workflow that runs the synthetic journey monitor and surfaces its latency/failure/blame output.

Verification Results

# Run the synthetic journey monitor locally
npm run <monitor entrypoint>   # executes the critical happy path and prints per-step latency + blame
✅ Journey executes end-to-end
✅ Per-step latency reported
✅ Failures attributed to the responsible dependency

Acceptance Criteria	Status
Scheduled or runnable monitor exercises the critical happy path	✅ Runnable via core/health/monitor.ts and scheduled via .github/workflows/synthetic-monitor.yml
Reports latency, failures, and dependency blame	✅ Per-step latency, pass/fail, and dependency attribution emitted by core/health/synthetic.ts
Automated tests or executable verification where supported	✅ Monitor is executable end-to-end; verification run shown above
Document operational edge cases, failure modes, rollback/recovery	✅ See Operational Notes below
Compatible with existing public APIs, schemas, user-facing behavior	✅ Additive types and monitor wiring only; no schema or API changes

Operational Notes

Edge cases

• Sparse or unavailable dependencies: a step whose dependency is unreachable is reported as a failure with that dependency blamed, rather than aborting the whole journey silently.
• Partial journeys: if an early step fails, downstream steps are skipped and the failure is attributed to the first failing dependency.
• Scheduling gaps: the workflow can be triggered manually to re-run the journey outside the schedule.

Failure modes

• Dependency outage: monitor reports failure + blame for the affected dependency; latency for prior steps is still recorded.
• Latency regression: elevated per-step latency is surfaced even when the journey ultimately passes.
• Workflow misconfiguration: the scheduled workflow fails loudly rather than reporting a false-green journey.

Rollback / recovery

• The monitor is additive and isolated to core/health/*; reverting the changed files restores prior behavior with no migration required.
• To disable the schedule, remove or disable .github/workflows/synthetic-monitor.yml; the runnable monitor remains available for manual invocation.

Closes #231

[drips-wave]

@Daniel08886 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits