Databases
AuraScore 81/100

Production Database Performance Remediation Directive

Issue an actionable engineering alert email regarding slow database queries, index optimizations, and remediation deadlines.

Use this template when query latency breaches SLO thresholds and application developers need clear guidance on query refactoring, missing indexes, and read-replica offloading. It turns database telemetry into prioritized remediation steps.

Template

Role: Staff Database Reliability Engineer responsible for high-throughput OLTP database tuning, indexing strategies, and query performance.

Context

  • Recipient engineering group: {{engineering_team}}
  • Primary database engine: {{primary_database_type}}
  • Service level objective threshold: {{p99_latency_threshold}}
  • Remediation review deadline: {{incident_review_date}}
  • Identified query bottlenecks: {{slow_query_patterns}}
  • Replica tier configuration: {{read_replica_status}}

Task

Author a high-priority engineering notification email to {{engineering_team}} highlighting critical database query latency degradation, prescribing targeted indexing and query refactoring fixes, and establishing a firm remediation cutoff.

Method

  1. Highlight the current latency metrics exceeding the {{p99_latency_threshold}} threshold on {{primary_database_type}}.
  2. Itemize the top degrading query signatures identified in {{slow_query_patterns}} with their table scan impacts.
  3. Analyze missing or redundant indexes contributing to buffer cache churn and lock contention.
  4. Recommend query refactoring patterns (e.g., keyset pagination, selective projection, CTE optimization).
  5. Explain how to offload analytical or read-heavy traffic using {{read_replica_status}}.
  6. Provide exact DDL index creation guidelines with concurrent/online execution flags to prevent table locks.
  7. Establish the verification criteria and testing steps required ahead of the {{incident_review_date}} deadline.

Constraints

  • MUST specify zero-downtime index creation syntax appropriate for {{primary_database_type}}.
  • MUST NOT suggest vertically scaling hardware as a substitute for query optimization.
  • MUST include explicit benchmark criteria to confirm query remediation.
  • Keep communication strictly technical, constructive, and oriented toward rapid engineering execution.

Output format

  • Subject line: Performance Alert: Query Optimization Required for {{primary_database_type}} [Deadline: {{incident_review_date}}]
  • Telemetry Summary (2-3 concise sentences on latency spikes)
  • Query Analysis & Recommended Fixes (bulleted list per slow query pattern)
  • Deployment Safeguards (rules for rolling out index updates)
  • Next Steps & Sign-off Deadline (clear checklist)
  • Total length: 300-450 words

Self-review

  • Ensure the {{p99_latency_threshold}} metric is explicitly tied to customer impact or SLA risk.
  • Check that online DDL execution constraints are clearly stated to avoid production lockouts.
  • Confirm the review deadline is emphasized in both the header and conclusion.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-databases
research-productivity-operations
databases
performance
reliability