Skip to content
  • There are no suggestions because the search field is empty.

Monitor and Recover PBRS API Executions

Correlate API requests with scheduler work, verify delivery and recover safely from stalled or long-running executions.

Review status: Draft for Development and Support review. Routes and models labelled validation required must be tested against the supported PBRS build before publication.

Record a correlation envelope

  • Client request timestamp and timezone
  • PBRS build and server
  • Sanitized route and operation
  • Schedule identifier and schedule type
  • Execution identifier and RunBy value
  • Terminal state and sanitized ResultJson
  • Expected artifact and destination result

Monitoring sequence

  1. Confirm the API accepted the request.
  2. Correlate the execution identifier with PBRS queue or history data.
  3. Poll at a bounded cadence until a terminal state or client timeout.
  4. Parse ResultJson and identify source, rendering and destination outcomes.
  5. Verify each expected artifact and delivery independently.
  6. Reconcile ambiguous or timed-out requests before any retry.

Recovery sequence

  1. Attempt the documented cancellation operation when supported.
  2. Inspect the current execution queue and available scheduler threads.
  3. Use the build-supported UI termination action for a long-running job.
  4. Escalate to service or process intervention only under the approved runbook.
  5. After recovery, confirm service health and reconcile affected schedules and deliveries.

Queue termination and any legacy process-level fallback are build-sensitive. Document the introducing build and operator permissions before publication.

Synthetic monitoring schedule

Use a harmless, allow-listed schedule with a controlled destination as an end-to-end probe. Run it at an interval appropriate to the environment and alert separately when:

  • the API service cannot be reached;
  • ping succeeds but authentication or a protected read fails;
  • the scheduler is stopped;
  • queue depth or oldest execution age exceeds the tested baseline;
  • the execution reaches no terminal state within the client timeout;
  • the API reports completion but the expected artifact or destination acknowledgement is missing.

Long-running job recovery

  1. Identify the execution using ExecutionId, schedule, server, time and process ID.
  2. Attempt the documented API cancellation if the build supports it.
  3. Use the current API Execution Queue termination action when available and authorized.
  4. Use process-level termination only as an approved legacy fallback; record the process ID and affected execution first.
  5. Before restarting services, identify unsafe automation jobs that must not rerun automatically.
  6. After recovery, verify API/scheduler health, reconcile outputs and decide deliberately which work to rerun.

Documentation standard: Record the PBRS build used for verification, test in a non-production environment, redact credentials and customer data, and confirm the saved PBRS state after every write.