pipelogiqOperate workflows in the dashboard
A practical guide for support staff, business operators, and administrators to inspect and recover runs.
Use the dashboard to answer what happened to a business operation and what should happen next. The pipeline ID identifies one run; context and labels connect that run to an invoice, customer request, order, or other record in your application.
Choose the right access
| Role | What the dashboard is for |
|---|---|
| Viewer | Investigate assigned pipelines and schedules, inspect statuses, logs, context, and results. |
| Operator | Investigate and use pipeline/schedule operation controls in assigned applications. |
| Admin | Operate assigned applications and manage users, access, API keys, policies, observability, and audit settings. |
Application membership controls which data a person sees. An administrator can manage accounts without automatically seeing every application's pipeline data. A missing run may be an access issue. Ask an administrator to check membership instead of creating a duplicate run.
Find the business operation
- Open Pipelines.
- Narrow the list using the available status, time, label, and context filters. Use the identifier recorded by the application when available.
- Open the matching run and confirm its pipeline name, application, creation time, and run ID.
- Share the run's dashboard URL with a colleague who has access to the same application.
Sensitive context values are redacted and are not suitable for search. Ask application developers to include non-sensitive business identifiers such as orderId or requestId for support investigations.
Read the run
| Tab | Use it to answer |
|---|---|
| Stages | Which step is running, waiting, failed, skipped, or complete? How many attempts were made? |
| Logs | What did handlers and execution processing report? Which stage produced a message? |
| Context | Which business identifiers and shared values are associated with the run? |
| All data | What is the returned run payload, including metadata useful to engineering? |
Expand a stage to inspect its handler, input, output, error information, timing, and retries. Run info includes trace and idempotency identifiers when present. Live updates arrive through WebSockets; use refresh if the connection has been interrupted.
Interpret a waiting run
- NotStarted: the stage has not been dispatched. Earlier stages, dependencies, a paused pipeline, or worker availability may explain the wait.
- Pending: work has entered dispatch/execution coordination. Check the handler and worker if it stays here.
- Running: a worker is executing the stage.
- RetryScheduled: a reported failure has an automatic retry time. Investigate the cause rather than adding a manual retry immediately.
- Throttled: a policy delayed dispatch. An administrator can inspect matching policies.
- WaitingForApproval: the application must supply a decision through the SDK/API. There is no dashboard approval button.
- Failed: the current attempt ended without completing the step. Read its error and retry history before acting.
Completed, Skipped, and Cancelled have different business meanings. A skipped stage did not successfully execute; a cancelled pipeline does not mean prior external actions were reversed.
Recover a failed stage
Operators and administrators can use Rerun stage or Skip stage when the stage is Failed and the pipeline is not Cancelled.
- Record the run and stage IDs and read the latest error.
- Check the relevant external system if the handler could have completed a side effect before losing its response.
- Resolve the cause: repair input in the originating system, restore a dependency, or ask engineering to fix the handler.
- Choose Rerun stage when executing it again is appropriate. This queues the selected stage again; it does not reset every later stage.
- Choose Skip stage only when your process permits continuing without its result.
- Watch the next state and inspect downstream stages to confirm the intended outcome.
If you only have Viewer access, send the run URL and observed error to the authorized operator. Read-only visibility is intentional, not a failed page load.
Pause pipelines and manage schedules
Use Pause pipeline to stop further dispatch while investigating. Work already executing may finish. Use Resume pipeline after the issue is resolved. Terminal pipelines do not have ordinary pause/resume controls.
Under Schedules, inspect next/last run and recent outcomes. Open a schedule for its stored definition and run history. Operators can pause, resume, archive, run now, and edit the exposed schedule policies. A manual run can include an input override and creates a separate pipeline. Read schedule behavior before manually rerunning a scheduled business task.
Bulk actions in the pipeline list operate on selected targets. Review the selection first and read per-target results afterward; a bulk response can contain both successes and failures.
Administrator investigation
Administrators can inspect worker state and events from the dashboard, configure observability, and open Settings → Audit for human activity. Filter audit by action, user, and outcome, then expand an event to see selected details and bulk results.
Human activity audit does not contain every SDK request or scheduler firing. Use pipeline, schedule, and worker history for execution activity. See access and audit and troubleshooting.
Workflow authoring, dynamic stage append, pipeline cancellation, and approval decisions are SDK/API responsibilities. The dashboard is the operational view for those workflows.