Skip to content
API reference Go to app

Observatory Best Practices

1 min read

Observatory works best when dashboards are designed around decisions, not decoration. Start with the question your team needs to answer, then choose the smallest useful set of charts.


Before creating a panel or chart, decide what the dashboard should help answer.

Good questions include:

  • Are we ready to ship this release?
  • Which executions are carrying the most risk?
  • Which requirements have weak test coverage?
  • Which defects are putting quality at risk?
  • Is automation improving coverage in the right places?

If a chart does not support the question, leave it out.


Panels are easiest to review when they include a focused set of charts.

Useful guidelines:

  • Start with 4 to 8 charts
  • Put summary charts first
  • Keep related charts near each other
  • Split broad panels into smaller dashboards
  • Remove charts that no longer support a decision

Use chart types intentionally:

  • Bar: compare categories
  • Stacked Bar: compare categories with a second breakdown
  • Line: show trends over time
  • Pie or Doughnut: show simple distribution at a point in time
  • Radar: compare multiple dimensions carefully

Avoid using a more complex chart when a simpler chart explains the result better.


Execution progress and execution quality are related, but they are not the same.

A run can be nearly complete and still have high failure or blocker risk. Use separate charts for:

  • Completion or execution status
  • Passed, failed, blocked, skipped, and not executed results
  • Linked defects
  • Requirement coverage

As a project changes, dashboards should change with it.

During regular review:

  • Rename panels that no longer describe their purpose
  • Update descriptions when the audience changes
  • Delete panels that are no longer useful
  • Replace repeated manual analysis with Smart Insights or Custom Builder charts