Observability
Part of Workflow monitoring and observability
Building a workflow health dashboard
Lay out outcomes, backlog and execution signals with clear definitions, data freshness and routes to affected records.
Build the workflow health dashboard around the owner's first decision: is eligible work reaching its confirmed destination outcome, and which items need attention now? Put outcomes and overdue work at the top. Below them, use execution and dependency signals to explain change. Each concerning measure needs a route to its underlying records.
Define the view before choosing charts
Select the workflow, environment and reporting window. With the systems' owners, define the source cohort, destination result and deadline. Show when each data feed last refreshed. A missing or delayed feed must not appear as a healthy zero.
| Area | Measures | Decision supported | Data source |
|---|---|---|---|
| Outcomes | Eligible source items, confirmed results and on-time confirmations | Is the intended work getting done? | Authoritative source and destination business records |
| Open work | Pending and outcome-unknown items; overdue subset and oldest age | What needs attention now? | Source and destination records, with timestamps and deadlines |
| Execution | Started and completed runs, action failures and retries | Where might processing have stopped? | Platform run history and diagnostic logs; Azure Monitor Metrics where applicable |
| Waiting work | Queue age or destination throttling, where available | Is work accumulating? | Queue telemetry or destination-service metrics, where available |
Label units clearly. An accepted request is not a completed business action; runs are not unique business items. A daily view should show new eligible work and older unresolved work, so a quiet day does not hide a backlog.
Connect summaries to records
Give each actionable measure a filtered record list or saved query. An overdue count should lead to source IDs, age, last confirmed stage and owner. A failure measure should lead to the relevant run or safe error category. Preserve the destination result ID where confirmation exists.
Use breakdowns that help an operator decide: workflow version, source event class, destination and status. Keep production separate from test activity.
Put individual item IDs in drill-down records rather than creating a chart series for each one. Show a data-quality warning if source intake, destination confirmation or diagnostic feeds stop updating.
Map platform signals to their actual meanings
For Azure Logic Apps, workflow performance data is available through Azure Monitor Metrics. The Standard metrics list includes Workflow Action Completed Count, which counts completed actions regardless of status, and Workflow Actions Failure Rate. Job execution timing is also workflow performance data.
The Azure Logic Apps Metrics view supports filters for a specific workflow or status. Check the metric namespace for the deployed Logic Apps type.
Logic Apps trigger history lists trigger attempts; a Skipped status means the trigger checked the endpoint but found no data meeting the specified criteria.
AWS Step Functions says CloudWatch metrics are delivered on a best-effort basis, so their completeness and timeliness are not guaranteed.
Treat these product signals as operational indicators; derive the business outcome count from the authoritative source and destination records.
Using Platform Signals vs Business Records
- Pros of Platform Signals (e.g., Azure Monitor Metrics)Real-time execution tracking, integration with ATO-compliant logging, supports drill-down to run history
- Cons of Platform SignalsMay not reflect actual business outcomes; Skipped triggers do not indicate failure, only lack of input data
- Pros of Business RecordsConfirms real-world outcome; aligns with GST reporting and superannuation reconciliation processes
- Cons of Business RecordsMay lag due to manual confirmation; requires dedicated reconciliation workflows
Show change and uncertainty
Place trends for confirmed outcomes and overdue work beside current values. Mark workflow releases or source-contract changes so periods can be interpreted sensibly. Keep pending, known failure and outcome unknown distinct.
After a write times out, the unknown item should lead to destination reconciliation rather than an assumption that nothing was created.
Set owner notifications from the business deadline and impact. Show the affected-item count and oldest age for an incident while preserving individual cases. Alert routing belongs in the operating process; a chart threshold alone does not assign an owner.
Before relying on the dashboard, compare its tiles and drill-downs with known completed, ineligible, overdue, skipped-trigger and lost-response cases in the intended environment. Check what appears when one feed is late. Record the expected result for each test case and verify that its tile and drill-down record agree.
