You get:
- optimizing the wrong workflows (spending time on low-impact changes)
- fixing symptoms instead of root causes (bottlenecks shift)
- redundant work (multiple workflows doing the same thing)
- failure points that go unaddressed (same errors repeat)
- no data-driven prioritization (gut-feeling improvements)
But optimization opportunities are measurable:
- bottlenecks: slowest workflows in the critical path
- redundancies: multiple workflows doing identical work
- failure points: workflows with highest error rates
- resource hogs: workflows consuming most API calls, compute, or time
- low-value workflows: high effort, low business impact
Without analysis, you optimize blindly.
This prompt identifies where to invest optimization effort.
Assume the role of a system performance analyst who identifies optimization opportunities. Your task is to analyze workflow system data and recommend where to invest improvement efforts. Generate: 1. PERFORMANCE METRICS SUMMARY | Workflow | Avg Duration | p95 Duration | Run Frequency | Monthly Runtime | Error Rate | |----------|--------------|--------------|---------------|-----------------|------------| | WF-001 | 2s | 5s | 10k/day | 5.5 hours | 0.5% | | WF-002 | 30s | 120s | 1k/day | 8.3 hours | 5% | 2. BOTTLENECK IDENTIFICATION - Slowest workflows (p95 latency) - Critical path workflows (block downstream workflows) - Queued workflows (waiting for resources) 3. REDUNDANCY DETECTION - Workflows doing similar work: [list] - Overlap percentage: [X%] - Consolidation opportunity: [hours saved] 4. FAILURE POINT ANALYSIS - Highest error rate workflows: [list] - Most common error types: [list] - Impact per failure (data loss, customer impact) 5. RESOURCE CONSUMPTION - API call leaders: [workflows with most external calls] - Compute leaders: [workflows with longest runtime] - Cost leaders: [workflows with highest operational cost] 6. LOW-VALUE WORKFLOWS - Workflows with low business impact: [list] - Effort to maintain: [hours/month] - Recommendation: [automate further / deprecate / maintain] 7. OPTIMIZATION PRIORITIES (ranked by ROI) | Priority | Workflow | Issue | Fix | Expected Improvement | Effort | |----------|----------|-------|-----|---------------------|--------| | 1 | WF-002 | High error rate | Add retry | 80% error reduction | 2 days | | 2 | WF-001 | Slow p95 | Parallelize | 60% latency reduction | 3 days | INPUTS: Workflow performance data (from monitoring): [PASTE DURATIONS, FREQUENCIES, ERROR RATES] Critical path map (from WS-02): [PASTE DEPENDENCY GRAPH] Business impact per workflow: [E.G., "WF-003 (invoicing) is revenue-critical; WF-007 (logging) is nice-to-have"] Available engineering capacity: [E.G., "2 engineers, 20 hours/week for optimization"] RULES: - Optimize by ROI, not by convenience (highest impact first) - Bottlenecks on the critical path matter most (optimize there first) - High error rates often indicate flaky dependencies (add retries, timeouts) - Redundancy consolidation saves maintenance, not just runtime - Low-value workflows should be deprecated (not optimized) - Measure before optimizing (baseline required to prove improvement)
- Optimize by ROI, not by convenience — highest impact first.
- Bottlenecks on the critical path matter most — optimize there first.
- High error rates often indicate flaky dependencies — add retries and timeouts.
- Redundancy consolidation saves maintenance effort, not just runtime.
- Low-value workflows should be deprecated, not optimized.
- Measure before optimizing — you need a baseline to prove improvement.
Workflow performance data:
“WF-001 (Lead Capture): avg 2s, p95 4s, 50k/day, error rate 0.2%. WF-002 (Lead Scoring): avg 15s, p95 60s, 50k/day, error rate 8%. WF-003 (Reporting): avg 180s, p95 300s, 1/day, error rate 0%. WF-004 (Customer Sync): avg 45s, p95 120s, 10k/day, error rate 3%.”
Critical path map:
“WF-001 → WF-002 → WF-003. WF-004 is independent.”
Business impact per workflow:
“WF-001 and WF-002 are revenue-critical (lead processing). WF-003 is internal reporting. WF-004 is customer-facing (sync delays cause support tickets).”
Available engineering capacity:
“1 engineer, 10 hours/week for optimization”
This framework improves outcomes by forcing:
- performance metrics summary (what does the data say?)
- bottleneck identification (where is the system slowest?)
- redundancy detection (what work is duplicated?)
- failure point analysis (where does it break most often?)
- ROI-based prioritization (what to fix first?)
Failure modes this prevents:
- Optimizing the wrong workflow — fast workflow, but not on critical path
- Fixing symptoms — adding cache when database is the real bottleneck
- Ignoring high-error workflows — “it’s only 5% failure rate” (that’s 2,500 failures/day)
- Maintaining low-value workflows — high effort, low business impact
This improves on: Gut-feeling optimization. Data-driven analysis identifies actual leverage points.
Related to: WS-02 (Dependencies) for critical path; WS-06 (Dashboard) for ongoing monitoring.
Build Better AI Systems
Subscribe for advanced prompt engineering, AI coding tools, debugging frameworks, and practical strategies for developers and engineers.