Skip to main content

Knowledge Graph Prompts library

Last updated on

Ask natural language questions about your software delivery workflows. The Knowledge Graph connects entities across pipelines, services, environments, and infrastructure to provide context-aware answers.

This page shows validated prompts organized by use case, how the graph traverses relationships, the HQL queries used, and sample outputs.

Validation Status

All prompts on this page have been validated against live Harness data. These queries are production-ready and tested with the Harness in-product experience and Harness APIs.


What will you learn in this topic?

By the end of this page, you will understand:

  • How to ask questions about pipeline failures, build times, and productivity.
  • How the Knowledge Graph connects entities to answer your questions.
  • What HQL queries power each prompt.
  • How to interpret query results.

Pipeline failure analysis

Analyze pipeline health, identify failure patterns, and get remediation recommendations.

Prompt 1: Which pipelines have the highest failure rate?

What it does: Identifies pipelines that fail most frequently and surfaces common failure points across stages and steps.

Graph traversal:

Pipeline Execution
├── status: FAILED
├── pipeline_id
└── Stage Execution
├── stage_name
└── Step Execution
├── step_name
├── step_type
└── failure_message

HQL queries:

# Query 1: Pipeline execution status distribution
find pipeline:pipeline_execution
| where start_ts > ago("30d")
| group by pipeline_id, status
| count

# Query 2: Failure codes
find pipeline:step_execution
| where status = "FAILED"
| where start_ts > ago("30d")
| group by failure_code
| count
| order by count desc

# Query 3: Stage-level failures
find pipeline:stage_execution
| where status = "FAILED"
| where start_ts > ago("30d")
| group by pipeline_id, stage_name, stage_type
| count
| order by count desc

# Query 4: Root cause (step-level)
find pipeline:step_execution
| where status = "FAILED"
| where start_ts > ago("30d")
| group by pipeline_id, stage_name, step_name, failure_code
| count
| order by count desc

Sample output:

PipelineTotal RunsFailedSucceededFailure Rate
agt_pipe2114066.7%
pipeline_0e7b110100%
pipeline_7d66101910%
test_tracing_v05050%

Root cause breakdown:

PipelineStageStepFailure CodeCount
agt_pipeagtrunEvalsAPPLICATION_FAILURE7
agt_pipeagtrunFeatureFlagCleanupAgentAPPLICATION_FAILURE4
agt_pipeDeployInitializeContainerGENERAL_ERROR2

Visual representation:

Pipeline: agt_pipe (66.7% failure rate)

├── Stage: agt (CI) → 11 failures
│ ├── runEvals → 7 APPLICATION_FAILURE
│ └── runFeatureFlagCleanupAgent → 4 APPLICATION_FAILURE

└── Stage: Deploy → 4 failures
└── InitializeContainer → 2 GENERAL_ERROR

Prompt 2: Which pipelines failed the most in the last 30 days?

What it does: Ranks pipelines by total failure count to prioritize remediation efforts.

Graph traversal:

Pipeline Execution
├── status: FAILED
├── start_ts: last 30 days
└── group by pipeline_id

HQL query:

find pipeline:pipeline_execution
| where status = "FAILED"
| where start_ts > ago("30d")
| group by pipeline_id
| count
| order by count desc

Sample output:

PipelineFailures
agt_pipe14
pipeline_6a8d1
pipeline_173b1
pipeline_0e7b1

Visual representation:

Pipeline Failures (Last 30 Days)
────────────────────────────────
agt_pipe ██████████████ 14
pipeline_6a8d █ 1
pipeline_173b █ 1
pipeline_0e7b █ 1

Prompt 3: What stages fail most often across all my pipelines?

What it does: Identifies problematic stages across all pipelines for cross-pipeline insights.

Graph traversal:

Pipeline Execution
└── Stage Execution
├── status: FAILED
├── stage_name
└── pipeline_id

HQL query:

find pipeline:stage_execution
| where status = "FAILED"
| where start_ts > ago("30d")
| group by stage_name, pipeline_id
| count
| order by count desc

Sample output:

StagePipelineFailures
agtagt_pipe11
Deployagt_pipe4
Build_0pipeline_0e7b1
Stagepipeline_173b1

Visual representation:

Cross-Pipeline Stage Failures
──────────────────────────────
agt (agt_pipe) ███████████ 11 failures
Deploy (agt_pipe) ████ 4 failures
Build_0 (pipeline_0e7b) █ 1 failure
Stage (pipeline_173b) █ 1 failure

Prompt 4: Show me the top 5 error messages from failed pipelines

What it does: Surfaces the most common error messages to identify systemic issues.

Graph traversal:

Pipeline Execution
└── Stage Execution
└── Step Execution
├── status: FAILED
├── failure_message
└── count

HQL query:

find pipeline:step_execution
| where status = "FAILED"
| where start_ts > ago("7d")
| where failure_message != null
| group by failure_message
| count
| order by count desc
| limit 5

Sample output:

Error MessageCount
Pull access denied for nodejs, repository does not exist or may require 'docker login'1,793
Exit status 1 (generic shell error)78
Hosted infrastructure connector misconfiguration51
Exit status 12222
No eligible runners found18

Visual representation:

Top Error Messages (This Week)
───────────────────────────────
Docker pull failure ████████████████████ 1,793 (76%)
Exit status 1 ███ 78 (3%)
Connector config ██ 51 (2%)
Exit status 122 █ 22 (1%)
No runners █ 18 (1%)

Prompt 5: Recommend fixes for my most-failing pipeline

What it does: Analyzes error patterns and provides actionable remediation recommendations.

Graph traversal:

Pipeline Execution
├── failure count
└── Step Execution
├── failure_message
├── failure_code
└── step_type

HQL queries:

# Query 1: Find most-failing pipeline
find pipeline:pipeline_execution
| where status = "FAILED"
| where start_ts > ago("30d")
| group by pipeline_id
| count
| order by count desc
| limit 1

# Query 2: Analyze error patterns
find pipeline:step_execution
| where pipeline_id = "<most_failing_pipeline>"
| where status = "FAILED"
| where start_ts > ago("30d")
| group by step_name, failure_message
| count
| order by count desc

Sample output:

StepErrorCountRecommendation
runEvalsexit status 67Replace placeholder API credentials with actual secrets
runFeatureFlagCleanupAgentexit status 14Verify LLM connector configuration and credentials
InitializeContainerNo eligible runners found2Check delegate health and connectivity

Recommendations:

  1. Fix placeholder credentials in Agent steps (resolves 7 failures)
  2. Validate LLM connector configuration (resolves 4 failures)
  3. Ensure delegate availability (resolves 2 failures)

Build time analysis

Analyze build performance, identify bottlenecks, and optimize CI pipelines.

Prompt 6: Which builds are taking the longest?

What it does: Identifies slow pipelines and surfaces stage/step bottlenecks with optimization recommendations.

Graph traversal:

CI Stage Execution
├── pipeline_id
├── stage_build_time
└── Step Execution
├── step_name
├── step_type
└── duration

HQL queries:

# Query 1: Slowest pipelines
find pipeline:pipeline_execution
| where status = "SUCCEEDED"
| where start_ts > ago("30d")
| group by pipeline_id
| avg duration
| p95 duration
| max duration
| count
| order by avg_duration desc

# Query 2: Slowest step types
find pipeline:step_execution
| where status = "SUCCEEDED"
| where start_ts > ago("30d")
| group by step_type
| avg duration
| p95 duration
| max duration
| count
| order by avg_duration desc

Sample output:

Slowest pipelines:

PipelineAvg DurationP95 DurationMax DurationRuns
Code Coverage151 min164 min164 min4
Worker Agent Demo27 min68 min68 min10
autofix17 min43 min43 min3

Slowest step types:

Step TypeAvg DurationMax Duration
Barrier164 min600 min
HarnessApproval119 min600 min
Background66 sec5.8 min
InitializeContainer53 sec2.6 min
Run4.6 sec164 min

Recommendations:

  • Parallelize AI agent workloads in Code Coverage pipeline
  • Reduce approval wait times with notifications
  • Optimize Windows build initialization
  • Enable caching for Maven builds

Prompt 7: What are my slowest builds in the last 30 days?

What it does: Ranks successful builds by duration to prioritize optimization efforts.

Graph traversal:

Pipeline Execution
├── status: SUCCEEDED
├── duration
└── pipeline_id

HQL query:

find pipeline:pipeline_execution
| where status = "SUCCEEDED"
| where start_ts > ago("30d")
| group by pipeline_id
| avg duration
| p95 duration
| max duration
| count
| order by avg_duration desc

Sample output:

PipelineAvg DurationP95 DurationMax DurationRuns
test-mcp-functor2m 3s2m 3s2m 3s1
pipeline_7d661m 34s4m 54s4m 54s9
test_tracing_v01m 23s1m 44s1m 44s5

Visual representation:

Slowest Successful Builds
──────────────────────────
test-mcp-functor ████ 2m 3s (1 run)
pipeline_7d66 ███ 1m 34s avg, 4m 54s P95 (high variance)
test_tracing_v0 ██ 1m 23s (5 runs)

Prompt 8: Which build stage takes the longest in my pipeline?

What it does: Identifies bottleneck stages within a specific pipeline.

Graph traversal:

Pipeline: <pipeline_id>
└── Stage Execution
├── stage_name
├── duration
└── status

HQL query:

find pipeline:stage_execution
| where pipeline_id = "agt_pipe"
| where start_ts > ago("30d")
| group by stage_name
| avg duration
| p95 duration
| max duration
| count
| order by avg_duration desc

Sample output:

StageAvg DurationP95 DurationMax DurationRuns
agt101.3 sec242.1 sec248.6 sec16
Deploy25.8 sec159.4 sec159.4 sec8

Visual representation:

Pipeline: agt_pipe - Stage Duration
────────────────────────────────────
agt stage: ████████████████████ 101.3s (bottleneck)
Deploy stage: █████ 25.8s

Recommendation: Investigate agt stage for optimization

Prompt 9: Why did my build time increase by 40% last week?

What it does: Detects temporal regressions by comparing week-over-week build times and identifying root causes.

Graph traversal:

CI Stage Execution
├── start_ts: week 1 vs week 2
├── stage_build_time
└── init_time

HQL queries:

# Query 1: Previous week average
find ci:stage_execution
| where status = "SUCCEEDED"
| where start_ts > ago("14d")
| where start_ts < ago("7d")
| group by pipeline_id
| avg stage_build_time

# Query 2: Current week average
find ci:stage_execution
| where status = "SUCCEEDED"
| where start_ts > ago("7d")
| group by pipeline_id
| avg stage_build_time

# Query 3: Init time analysis
find ci:stage_execution
| where status = "SUCCEEDED"
| where start_ts > ago("14d")
| group by pipeline_id
| avg init_time
| max init_time

Sample output:

Time PeriodAvg Build TimeAvg Init Time
Week 2-3 ago66 sec5-6 sec
Week 1-2 ago86 sec5-35 sec

Root cause: Init time variance increased from consistent ~5-6 sec to 5-35 sec.

Visual representation:

Build Time Regression Analysis
───────────────────────────────
Week 2-3 ago: ████████████ 66s (5-6s init)
Week 1-2 ago: ████████████████ 86s (5-35s init)

+30% regression

Root cause: Init time spiked to 35s (6x normal)
Recommendation: Check infrastructure availability

Prompt 10: Which test suites are the biggest bottleneck?

What it does: Identifies slow test suites and test execution bottlenecks in CI pipelines.

Graph traversal:

CI Stage Execution
├── stage_name: test stages
├── stage_build_time
└── Test Execution
├── test_suite
└── duration

HQL queries:

# Query 1: Test suite bottlenecks
find ci:test_execution
| where start_ts > ago("30d")
| group by test_suite_name
| avg duration
| max duration
| count
| order by avg_duration desc
| limit 10

# Query 2: CI stage bottlenecks (if no test data)
find ci:stage_execution
| where start_ts > ago("30d")
| group by stage_name, pipeline_id
| avg stage_build_time
| max stage_build_time
| avg init_time
| count
| order by avg_stage_build_time desc

Sample output:

CI Stage Bottlenecks:

StagePipelineAvg Build TimeMax Build TimeAvg Init TimeRuns
agt-101.1s248.3s22.4s16
test-79.0s93.6s15.3s6

Recommendations:

  • Enable Test Intelligence on test stages
  • Investigate agt stage for optimization opportunities
  • Reduce init times (15-33s is high)

Prompt 11: Which builds have the most cache misses?

What it does: Identifies pipelines without caching enabled to prioritize optimization.

Graph traversal:

CI Stage Execution
├── optimization_state: NONE
├── pipeline_id
└── stage_build_time

HQL query:

find ci:stage_execution
| where optimization_state = "NONE"
| where start_ts > ago("30d")
| group by pipeline_id
| count
| sum stage_build_time
| order by count desc

Sample output:

PipelineCache MissesTotal Build Time Wasted
agt_pipe1626m 58s
pipeline_7d66105m 39s
pipeline_0e7b23s

Visual representation:

Cache Miss Distribution (Last 30 Days)
───────────────────────────────────────
agt_pipe: ████████████████ 16 misses (53%)
pipeline_7d66: ██████████ 10 misses (33%)
pipeline_0e7b: █ 2 misses (7%)

Total wasted time: 32m 40s
Recommendation: Enable Cache Intelligence on agt_pipe

Pipeline productivity

Get actionable recommendations to improve pipeline efficiency and reduce costs.

Prompt 12: What are the top recommendations to improve pipeline productivity?

What it does: Analyzes pipeline execution patterns and provides ranked optimization recommendations.

Graph traversal:

Pipeline Execution
├── Cache miss analysis
├── Approval wait times
├── Step durations
└── Failure patterns

HQL queries:

# Query 1: Cache miss opportunities
find ci:stage_execution
| where optimization_state = "NONE"
| where start_ts > ago("30d")
| group by pipeline_id
| count
| sum stage_build_time
| order by sum_stage_build_time desc

# Query 2: Long-running steps
find pipeline:step_execution
| where start_ts > ago("30d")
| group by step_type
| avg duration
| count
| order by avg_duration desc

# Query 3: High failure rate pipelines
find pipeline:pipeline_execution
| where start_ts > ago("30d")
| group by pipeline_id, status
| count

Sample recommendations:

  1. Enable caching on agt_pipe (saves 27 min/week)
  2. Reduce approval wait times in Worker Agent Demo (avg 71 min)
  3. Fix high-failure pipelines (agt_pipe at 66.7% failure rate)
  4. Parallelize background services in multibg pipeline

Prompt 13: Where am I wasting the most compute time on cache misses?

What it does: Quantifies time and cost wasted due to missing or disabled caching.

Graph traversal:

CI Stage Execution
├── optimization_state: NONE
├── stage_build_time
└── pipeline_id

HQL query:

find ci:stage_execution
| where optimization_state = "NONE"
| where start_ts > ago("30d")
| group by pipeline_id
| count
| sum stage_build_time
| order by sum_stage_build_time desc

Sample output:

PipelineCache MissesWasted Time% of Total Waste
agt_pipe1626m 58s53%
pipeline_7d66105m 39s33%
pipeline_0e7b23s7%

Total wasted time: 32m 40s across 30 days

Recommendation: Enable Cache Intelligence on agt_pipe to save 27 min/week


Prompt 14: How can I reduce my CI costs without increasing build time?

What it does: Identifies cost optimization opportunities that don't compromise build speed.

Validation: ✅ Validated - 100% success rate

Graph traversal:

Pipeline Execution
├── Resource usage patterns
├── Cache opportunities
└── Parallelization potential

HQL queries:

# Query 1: Cache Intelligence opportunities
find ci:stage_execution
| where optimization_state = "NONE"
| where start_ts > ago("30d")
| group by pipeline_id
| count
| sum stage_build_time

# Query 2: Serial vs parallel opportunities
find pipeline:stage_execution
| where start_ts > ago("30d")
| group by pipeline_id
| avg duration
| count

Sample recommendations:

  1. Enable Cache Intelligence: Saves 32m 40s/month (53% on agt_pipe)
  2. Use Harness Cloud: Reduce delegate overhead (saves infrastructure costs)
  3. Parallelize stages: Reduce wall-clock time without adding compute
  4. Right-size runners: Match compute to workload needs

Flaky test identification

Track test reliability, identify flaky tests, and measure retry costs.

Prompt 15: Which tests are flaky in my CI pipelines?

What it does: Identifies tests that fail intermittently and calculates retry cost.

Validation: ✅ Validated - 100% success rate

Graph traversal:

Test Execution
├── test_name
├── status: FAILED then SUCCEEDED
└── retry_count

HQL query:

find ci:test_execution
| where start_ts > ago("30d")
| group by test_name, pipeline_id
| count
| where retry_count > 0
| order by retry_count desc

Sample output:

Test NamePipelineFailuresRetriesSuccess Rate
integration.api.test_timeoutapi-service122466%
e2e.checkout.flaky_assertionweb-frontend81675%
unit.database.connection_poolbackend51080%

Total retry cost: 45 min/week wasted on retries


Prompt 16: Which tests fail intermittently across my pipelines?

What it does: Identifies tests with inconsistent pass/fail patterns.

Validation: ✅ Validated - 100% success rate

Graph traversal:

Test Execution
├── test_name
├── pass count
└── fail count

HQL query:

find ci:test_execution
| where start_ts > ago("30d")
| group by test_name
| count by status
| where fail_count > 0 AND pass_count > 0
| order by fail_count desc

Sample output:

Test NamePassedFailedFlake Rate
integration.api.test_timeout81260% fail
e2e.checkout.flaky_assertion12840% fail
unit.database.connection_pool15525% fail

Prompt 17: How many build minutes are wasted on retries per week?

What it does: Calculates the cost of test retries across all pipelines.

Graph traversal:

Test Execution
├── retry_count
└── duration

HQL query:

find ci:test_execution
| where start_ts > ago("7d")
| where retry_count > 0
| sum duration

Sample output:

WeekRetry CountWasted Time
Current15645 min
Previous14238 min
2 weeks ago13541 min

Average: 41 min/week wasted on test retries


Prompt 18: Which flaky tests are getting worse over time?

What it does: Tracks flaky test trends to identify degrading test quality.

Graph traversal:

Test Execution
├── test_name
├── start_ts (time buckets)
└── failure_rate by week

HQL query:

find ci:test_execution
| where start_ts > ago("60d")
| group by test_name, week_bucket(start_ts)
| count by status
| order by test_name, week_bucket

Sample output:

Test Name4 weeks ago3 weeks ago2 weeks agoLast weekTrend
integration.api.test_timeout20% fail40% fail50% fail60% fail📈 Worsening
e2e.checkout.flaky_assertion50% fail45% fail40% fail40% fail📉 Improving

Prompt 19: What's causing my integration tests to be flaky?

What it does: Analyzes flaky test patterns to identify root causes (timing, resources, isolation).

Graph traversal:

Test Execution (flaky tests)
├── failure_message patterns
├── execution time variance
└── infrastructure correlation

HQL queries:

# Query 1: Common failure messages for flaky tests
find ci:test_execution
| where retry_count > 0
| where start_ts > ago("30d")
| group by failure_message
| count
| order by count desc

# Query 2: Timing variance
find ci:test_execution
| where test_name in [<flaky_tests>]
| group by test_name
| avg duration
| stddev duration

Sample root causes:

Test NameRoot CauseEvidence
integration.api.test_timeoutTiming issueHigh duration variance (2s - 35s)
e2e.checkout.flaky_assertionResource contentionFails more on shared runners
unit.database.connection_poolTest isolationFails when run after specific tests

Recommendations:

  • Increase timeouts for timing-sensitive tests
  • Use dedicated runners for resource-intensive tests
  • Improve test isolation and cleanup