View and Monitor the PBRS API Execution Queue

The API Execution Queue shows schedules that have been submitted for execution through the PBRS REST API. Use it to review queued and active work, examine execution identifiers and status information, and investigate API-submitted schedules that have not produced the expected result.

Open the API Execution Queue

Open PBRS.
Select System Monitor.
Select API Execution Queue.

The queue displays the execution records available in the current PBRS environment.

Review an execution

Locate the execution you want to investigate and review the information available for it.

Depending on its current state, an execution record can include:

The schedule name and type.
The schedule’s unique ID.
The execution ID assigned to the submitted request.
The current execution status.
The server processing the execution.
The submission and completion times.
The user or integration that submitted the request.
The reported execution result or error information.

The schedule’s unique ID identifies the PBRS schedule. The execution ID identifies one specific attempt to run that schedule. Do not use these values interchangeably.

Understand execution status

Commonly observed execution states include:

Waiting: PBRS has accepted the execution, but processing has not started.
Executing: PBRS is currently processing the schedule.
Completed: PBRS has finished processing the execution.

A completed execution record does not necessarily confirm that every report was rendered or delivered successfully. Review the reported result and confirm the expected output at its destination.

Investigate a waiting execution

If an execution remains in the waiting state:

Confirm that the PBRS scheduler is running.
Check whether other schedules are already using the available execution capacity.
Confirm that the target schedule exists and is correctly configured.
Review the System Monitor for other active or delayed work.
Avoid submitting the same execution again until you have reconciled the original request.

Repeatedly submitting the same schedule can create duplicate reports or deliveries.

Investigate a long-running execution

If an execution remains in the executing state longer than expected, review:

Access to the report source.
Report rendering time.
Dataset or report-source availability.
Schedule filters and parameters.
Destination connectivity and permissions.
Other concurrent executions.
The applicable PBRS history, error, and delivery records.

A report can take longer to complete because of report complexity, source-system performance, rendering requirements, or destination availability.

Investigate a completed execution

If the queue shows that an execution completed but the expected output is missing:

Review the execution result for an error.
Check the schedule’s History record.
Confirm that the expected report was produced.
Verify the configured destination.
Check the applicable email, retry, or delivery queue.
Review the PBRS Error Log when the result indicates a failure.
Confirm that the destination credentials and permissions remain valid.

Execution completion and successful delivery are separate checks.

Reconcile before retrying

Before submitting a schedule again:

Record the original execution ID.
Check the API Execution Queue.
Review the schedule’s History record.
Inspect the expected destination.
Determine whether rendering or delivery already occurred.
Retry only after confirming that another submission will not create an unwanted duplicate.

This is particularly important for schedules that send email, write files, or deliver reports to external systems.

Monitor executions through the API

Applications can also monitor an asynchronous execution programmatically using its execution ID.

For API operations, status handling, cancellation, recovery, and result interpretation, see:

For a complete PowerShell example, follow Authenticate, Execute, and Monitor a Schedule.