30 Claude Prompts for Grafana

You are a Prometheus and PromQL specialist helping a backend team instrument dashboards correctly. <context> I have request counters split by status code and I need a query that shows the percentage of requests failing over a rolling window, not just the raw error count. </context> <inputs> - Metric name: [METRIC NAME] - Labels available: [LABEL LIST] - Error status codes to count: [STATUS CODE RANGE] - Rolling window: [TIME WINDOW] </inputs> <task> Write a PromQL expression that computes the error rate as a percentage over the given rolling window, using the counter and labels provided. </task> <constraints> Use rate or irate correctly for a counter metric, do not divide raw counters without a rate function. Handle the case where total requests could be zero without returning a division error. Explain in one sentence why you chose rate over irate or the reverse. </constraints> <format> Return the PromQL expression in a code block, followed by a short explanation of each part of the query. </format>

You are a Prometheus expert who writes production grade PromQL for latency histograms. <context> Our service exposes a histogram metric for request duration and I need the 95th percentile latency broken down by endpoint for a dashboard panel. </context> <inputs> - Histogram metric name: [METRIC NAME] - Label to group by: [LABEL LIST] - Percentile needed: [PERCENTILE VALUE] - Rolling window: [TIME WINDOW] </inputs> <task> Write a PromQL expression using histogram_quantile that computes the given percentile latency, grouped by the specified label, over the rolling window. </task> <constraints> Assume the metric follows the standard bucket, sum, and count naming convention. Use rate on the bucket counter before applying histogram_quantile. Warn me if the bucket boundaries could make this percentile misleading. </constraints> <format> Return the PromQL expression in a code block, then a short note on how to check your histogram buckets are fine grained enough for this percentile. </format>

You are a Kubernetes and Prometheus specialist troubleshooting container performance. <context> We suspect some pods are being CPU throttled and I need a query that surfaces the throttling ratio per container so we can confirm it on a dashboard. </context> <inputs> - Namespace: [NAMESPACE] - Container metric prefix: [METRIC NAME] - Label for pod name: [LABEL LIST] - Rolling window: [TIME WINDOW] </inputs> <task> Write a PromQL expression that computes the fraction of time a container spent throttled versus its total CPU periods, for the given namespace. </task> <constraints> Use the standard cgroup CPU throttling counters, not a custom metric. Group results by pod and container so the panel can show which workload is affected. Keep the expression to a single line if possible. </constraints> <format> Return the PromQL expression in a code block, then one sentence describing what a throttling ratio above 0.1 would mean in practice. </format>

You are a Kubernetes reliability engineer who tracks workload stability across a cluster. <context> I want to catch crash looping pods before an on-call engineer gets paged, by charting the restart count trend rather than just the current total. </context> <inputs> - Cluster name: [CLUSTER NAME] - Namespace filter: [NAMESPACE] - Restart counter metric: [METRIC NAME] - Rolling window: [TIME WINDOW] </inputs> <task> Write a PromQL expression that shows the rate of pod restarts over the rolling window, grouped by namespace and pod, so a sudden spike stands out from a slow steady climb. </task> <constraints> Use increase rather than the raw counter value so restarts are visible as a rate, not a running total that only ever goes up. Exclude pods with zero restarts from the result set. Keep label cardinality reasonable for a busy cluster. </constraints> <format> Return the PromQL expression in a code block, then a one sentence recommendation for the alert threshold that usually indicates crash looping. </format>

You are a storage and capacity engineer who forecasts resource exhaustion using Prometheus. <context> We want a query that predicts when a volume will run out of disk space based on its current fill trend, so the team can act before a hard outage. </context> <inputs> - Filesystem metric name: [METRIC NAME] - Mount point label: [LABEL LIST] - Lookback period for trend: [TIME WINDOW] - Forecast horizon: [FORECAST HORIZON] </inputs> <task> Write a PromQL expression using predict_linear that estimates whether the given filesystem will hit zero free space within the forecast horizon. </task> <constraints> Base the trend on the lookback period specified, not a fixed default. Return a boolean style expression suitable for an alert condition, not just a raw number. Note the main limitation of linear forecasting for bursty disk usage. </constraints> <format> Return the PromQL expression in a code block, then two sentences on when predict_linear gives false positives. </format>

You are a site reliability engineer who designs alert rules based on error budgets rather than raw thresholds. <context> We track an SLO for our service and want an alert that fires when we are burning through the error budget too fast, instead of alerting on every single error spike. </context> <inputs> - Service name: [SERVICE NAME] - SLO target: [SLO TARGET] - Error budget window: [TIME WINDOW] - Notification channel: [ON CALL CHANNEL] </inputs> <task> Design a multi-window, multi-burn-rate alert rule for error budget consumption, including the short and long window pair typically used to balance speed and false positives. </task> <constraints> Include both a fast burn alert for urgent paging and a slow burn alert for a ticket instead of a page. State the exact burn rate multiplier used for each window pair. Do not propose a single flat threshold, that defeats the purpose of budget based alerting. </constraints> <format> Return a table with columns: alert name, short window, long window, burn rate threshold, and severity, followed by the PromQL condition for each row. </format>

You are an SRE responsible for reducing alert fatigue while still catching real latency regressions. <context> Our current latency alert pages the on-call for every brief spike, and the team has started ignoring it, so I need a design that only fires on sustained regressions. </context> <inputs> - Latency metric: [METRIC NAME] - Acceptable latency threshold: [ALERT THRESHOLD] - Short evaluation window: [TIME WINDOW] - Long evaluation window: [FORECAST HORIZON] </inputs> <task> Design an alert rule that requires the latency threshold to be breached across both a short and a long evaluation window before it pages anyone, reducing noise from brief blips. </task> <constraints> Explain the tradeoff between catching regressions fast and avoiding noisy pages. Recommend a for duration setting in Grafana alerting, not just a raw query threshold. Keep the final rule expressible in a single PromQL condition plus a for clause. </constraints> <format> Return the alert condition, the recommended for duration, and a two sentence explanation of the tradeoff you chose. </format>

You are a backend reliability engineer who monitors asynchronous processing pipelines. <context> Our job queue occasionally backs up faster than workers can drain it, and I want an alert that catches the growth trend before the backlog becomes a multi-hour delay for customers. </context> <inputs> - Queue name: [QUEUE NAME] - Queue depth metric: [METRIC NAME] - Normal processing rate: [ALERT THRESHOLD] - Notification channel: [ON CALL CHANNEL] </inputs> <task> Design an alert rule that fires when the queue depth is both above a fixed threshold and growing rather than shrinking, so a temporary spike that is already draining does not page anyone. </task> <constraints> Combine an absolute depth threshold with a trend condition using deriv or a similar rate function. State the severity level and who gets paged versus who gets a ticket. Avoid alerting on queue depth alone without the trend check. </constraints> <format> Return the PromQL condition combining both checks, the for duration, and the severity mapping in a short table. </format>

You are a platform engineer responsible for preventing certificate related outages. <context> We have had at least one outage caused by an expired TLS certificate and want a Grafana alert rule that gives the team enough lead time to renew before it becomes urgent. </context> <inputs> - Certificate domains to track: [CERT DOMAIN] - Days of warning needed: [FORECAST HORIZON] - Metric exporter used: [DATASOURCE NAME] - Notification channel: [ON CALL CHANNEL] </inputs> <task> Design a tiered alert rule for certificate expiry that escalates severity as the expiry date gets closer, rather than a single alert that fires only once. </task> <constraints> Include at least two tiers, an early warning as a ticket and a final warning as a page. State the exact day thresholds for each tier. Assume the metric reports seconds until expiry, not a boolean. </constraints> <format> Return a table with columns: tier, days before expiry, PromQL condition, and severity. </format>

You are an SRE lead running an alert quality review for an overloaded on-call rotation. <context> Our on-call engineers are burning out from alert noise and I want a structured plan to review and clean up existing Grafana alert rules over the next few weeks. </context> <inputs> - Number of active alert rules: [ALERT THRESHOLD] - Weeks of alert history available: [TIME WINDOW] - Team size: [TEAM COUNT] - Current biggest complaint: [METRIC LIST] </inputs> <task> Propose a step by step plan to audit existing alert rules, classify each as keep, tune, or delete, and roll out the changes without losing coverage for real incidents. </task> <constraints> Include a data driven step that counts how often each alert fired versus how often it led to real action. Do not recommend deleting alerts without checking their firing history first. Keep the plan to a timeline the team can execute in under a month. </constraints> <format> Return a numbered plan with a week by week timeline, and for each step the specific Grafana or Prometheus data you would pull to make the decision. </format>

You are a dashboard design expert who matches panel types to the shape of the underlying data. <context> I have latency data as a histogram and I am not sure whether a heatmap, a time series with percentile lines, or a bar gauge best communicates it to an on-call engineer under pressure. </context> <inputs> - Data type: [METRIC NAME] - Audience during use: [STAKEHOLDER GROUP] - Time range typically viewed: [TIME WINDOW] - Existing panel type, if any: [PANEL TYPE] </inputs> <task> Recommend the best Grafana panel type for visualizing this latency histogram, with reasoning based on how the audience will actually read it during an incident versus during a calm review. </task> <constraints> Compare at least two panel type options directly rather than only proposing one. State a clear downside for each option considered. Assume the audience has ten seconds to interpret the panel during an incident. </constraints> <format> Return a short comparison table of panel types with pros and cons, followed by a one sentence final recommendation. </format>

You are a Grafana dashboard designer who supports release engineering teams. <context> We deploy frequently and want a panel that makes it obvious whether the newest version is performing worse than the previous one, without engineers needing to manually compare two separate graphs. </context> <inputs> - Metric to compare: [METRIC NAME] - Version label: [VERSION A] - Previous version label: [VERSION B] - Comparison window: [TIME WINDOW] </inputs> <task> Design a panel, or small set of panels, that lets an engineer compare the chosen metric between two deploy versions side by side or overlaid. </task> <constraints> Use Grafana template variables so the versions being compared can change without editing the panel. Prefer an overlay approach over two separate panels if the metric supports it cleanly. Call out any risk of misleading comparison if traffic volume differs between versions. </constraints> <format> Return the panel design description, the template variables needed, and the PromQL pattern for each version's line. </format>

You are an SRE who designs the first screen an on-call engineer sees when a page fires. <context> When someone gets paged at 3am they need to know within 60 seconds whether the problem is real, and our current dashboard makes them hunt across five tabs to figure that out. </context> <inputs> - Service name: [SERVICE NAME] - Alerts that commonly fire: [ALERT THRESHOLD] - Dependencies to check: [METRIC LIST] - Runbook location: [RUNBOOK URL] </inputs> <task> Design a single triage panel set, ordered by what an on-call engineer should check first, second, and third, that answers is this real, is it us, and what do I do next. </task> <constraints> Limit the set to panels that can be read in under 60 seconds combined. Include a direct link panel to the runbook. Order panels by diagnostic priority, not by which team owns the metric. </constraints> <format> Return a numbered list of panels in the order an engineer should look at them, with the question each panel answers. </format>

You are a FinOps focused platform engineer who tracks cloud spend using exported billing metrics. <context> Finance keeps asking engineering for cost breakdowns and I want a Grafana dashboard that answers their common questions without a manual spreadsheet every month. </context> <inputs> - Cost data source: [DATASOURCE NAME] - Cost centers to break down: [COST CENTER] - Reporting period: [TIME WINDOW] - Budget target: [SLO TARGET] </inputs> <task> Propose a cost tracking dashboard layout with panels for total spend trend, breakdown by cost center, and budget versus actual comparison. </task> <constraints> Use a bar gauge or stat panel for budget versus actual so it reads as over or under at a glance. Avoid time series panels for anything that is naturally a single point in time comparison. Keep currency formatting consistent across all panels. </constraints> <format> Return a list of panels, each with title, panel type, and the aggregation used, followed by one note on refresh frequency for billing data. </format>

You are a data visualization specialist who works with time series traffic data. <context> We want to spot weekly and daily traffic patterns, like a Tuesday afternoon spike, and a plain time series line makes that pattern hard to see across months of data. </context> <inputs> - Traffic metric: [METRIC NAME] - Time range to analyze: [FORECAST HORIZON] - Grouping needed: [LABEL LIST] - Data source: [DATASOURCE NAME] </inputs> <task> Design a heatmap panel that shows traffic intensity by day of week and hour of day, so recurring patterns are visible immediately. </task> <constraints> Specify the bucket size for the heatmap so it neither looks too blocky nor too noisy. Explain the PromQL or transformation approach needed to reshape the data into day and hour buckets. Note when a heatmap is the wrong choice compared to a calendar panel. </constraints> <format> Return the panel configuration description, the query or transformation steps, and one sentence on when to use a calendar panel instead. </format>

You are an incident commander who prepares tooling for active outages. <context> During incidents our team wastes the first ten minutes opening separate dashboards for each dependency, and I want one war room dashboard assembled ahead of time. </context> <inputs> - Service name: [SERVICE NAME] - Key dependencies: [METRIC LIST] - Incident channel: [ON CALL CHANNEL] - Current incident id, if active: [INCIDENT ID] </inputs> <task> Design a war room dashboard that combines the service's own health signals with its top dependencies on one screen, built so it can be pulled up in seconds during a live incident. </task> <constraints> Group panels by dependency, not by metric type, so a responder can quickly rule dependencies in or out. Include an annotation track for deploys and config changes. Keep the panel count low enough to avoid a second scroll on a shared screen. </constraints> <format> Return the dashboard layout as rows per dependency, with the panels and the question each row answers. </format>

You are a reliability engineer who investigates cross-service incidents. <context> Our incidents often turn out to be caused by an upstream service, but our dashboards are siloed per team, which slows down finding the real root cause. </context> <inputs> - Affected service: [SERVICE NAME] - Suspected upstream services: [METRIC LIST] - Time of the anomaly: [TIME WINDOW] - Shared identifiers across services: [LABEL LIST] </inputs> <task> Design a correlation dashboard that overlays the affected service's error signal with the same time window from its suspected upstream services, so a shared spike is visually obvious. </task> <constraints> Align all panels to the exact same time window and time zone. Use a shared trace or request id label if available to link panels together. State clearly that correlation shown here is not proof of causation. </constraints> <format> Return the panel layout with each service's signal as a separate but time aligned panel, plus one sentence on how to confirm causation beyond this dashboard. </format>

You are a technical writer who works closely with an SRE team to reduce incident response time. <context> Our on-call engineers see an alert fire but do not always know what action to take, and I want a runbook that maps directly to the panels on our triage dashboard. </context> <inputs> - Alert name: [ALERT THRESHOLD] - Dashboard name: [DASHBOARD NAME] - Common root causes: [METRIC LIST] - Escalation contact: [ON CALL CHANNEL] </inputs> <task> Write a runbook for this alert that references the specific panels on the named dashboard an engineer should check, in order, and the action to take for each likely root cause. </task> <constraints> Write in plain, direct instructions, not narrative prose. Every diagnostic step must name the exact panel to look at. Include a clear escalation trigger for when to stop investigating and page someone else. </constraints> <format> Return the runbook as numbered steps: check panel, what a bad result looks like, and the action to take. </format>

You are a reliability engineer who runs blameless postmortems for production incidents. <context> After an incident we need a dashboard snapshot that clearly shows the timeline of what happened, for use in the postmortem document and review meeting. </context> <inputs> - Incident id: [INCIDENT ID] - Time range of the incident: [TIME WINDOW] - Key metrics affected: [METRIC LIST] - Deploy or change events during the window: [VERSION A] </inputs> <task> Design a post-incident review dashboard that lays out the timeline of the affected metrics alongside deploy and alert annotations, suitable for pasting into a postmortem document. </task> <constraints> Fix the time range to the exact incident window plus a buffer before and after. Include annotation markers for when alerts fired and when the fix was deployed. Avoid any panel that requires live data, this dashboard must be reproducible after the fact. </constraints> <format> Return the panel layout with annotation sources listed, plus one sentence on how to export it as an image for the postmortem doc. </format>

You are a platform engineer who maps service dependencies for a growing microservices architecture. <context> New engineers and even some on-call veterans do not have a clear picture of which services depend on which, and it slows down incident triage. </context> <inputs> - Core services: [METRIC LIST] - Data source for dependency data: [DATASOURCE NAME] - Trace or service mesh tool in use: [DATASOURCE NAME] - Update frequency needed: [TIME WINDOW] </inputs> <task> Design a dashboard that visualizes service dependencies and their current health, using a node graph panel or an equivalent Grafana panel type suited to relationship data. </task> <constraints> Recommend the specific Grafana panel type suited to graph or relationship data, and explain why a time series panel would not work here. State what data source or exporter is required to populate this panel type. Keep the visualization readable with at least twenty services. </constraints> <format> Return the panel type recommendation, the data requirements, and a two sentence explanation of the readability tradeoff at scale. </format>

You are a technical writer embedded with an SRE team who documents internal tooling. <context> New engineers join our team and get lost trying to understand what each dashboard panel means, since most of our dashboards were built quickly with no documentation attached. </context> <inputs> - Dashboard name: [DASHBOARD NAME] - Panels to document: [METRIC LIST] - Audience experience level: [STAKEHOLDER GROUP] - Related runbook, if any: [RUNBOOK URL] </inputs> <task> Write documentation for this dashboard that explains what each panel shows, what a normal value looks like, and what a concerning value looks like. </task> <constraints> Write for someone who joined the team this week, avoid assuming prior context. Include a normal versus concerning value for every panel documented. Keep each panel's explanation to three sentences or fewer. </constraints> <format> Return the documentation as a list, one entry per panel, with fields: panel name, what it shows, normal range, concerning range. </format>

You are a Grafana administrator standardizing tooling across an engineering organization. <context> Our dashboards have inconsistent names and no shared tags, which makes search inside Grafana nearly useless once you have more than a handful of dashboards. </context> <inputs> - Number of teams using Grafana: [TEAM COUNT] - Common dashboard purposes: [METRIC LIST] - Existing tag examples, if any: [TAG NAME] - Search behavior teams want: [STAKEHOLDER GROUP] </inputs> <task> Propose a naming convention and a tagging taxonomy for dashboards that makes search and filtering reliable across teams. </task> <constraints> Naming convention must be short enough to read on a browser tab. Tags must cover at least team, service, and dashboard purpose as separate dimensions. Provide three worked examples of dashboard names under the new convention. </constraints> <format> Return the naming rule, the tag taxonomy as a short list, and three example dashboard names with their tags. </format>

You are an SRE who onboards new hires onto the team's observability stack. <context> Every new hire asks the same set of questions about how our Grafana instance is organized, and I want a written guide so I stop repeating the same walkthrough. </context> <inputs> - Team name: [TEAM NAME] - Folder structure summary: [FOLDER NAME] - Most important dashboards: [DASHBOARD NAME] - Access request process: [PERMISSION MODEL] </inputs> <task> Write an onboarding guide that walks a new hire through how our Grafana instance is organized, which dashboards matter most, and how to request access to anything they cannot see. </task> <constraints> Structure the guide as a checklist a new hire can follow on their first day. Link each key dashboard to the situation where they would actually open it. Keep the entire guide under one page when printed. </constraints> <format> Return the guide as a checklist with short explanations under each item. </format>

You are a Grafana platform owner who wants to raise the quality bar for dashboards published across the company. <context> Anyone can currently publish a dashboard with no review, and quality varies wildly, so I want a lightweight checklist reviewers can use before approving a new dashboard. </context> <inputs> - Minimum panel count expected: [ALERT THRESHOLD] - Required metadata fields: [TAG NAME] - Common mistakes seen so far: [METRIC LIST] - Reviewer role: [TEAM NAME] </inputs> <task> Draft a review checklist a reviewer can run through in under five minutes before approving a new dashboard for publication. </task> <constraints> Limit the checklist to items that are objectively checkable, not subjective taste. Include a check for template variables being used instead of hardcoded values. Keep the checklist to 10 items or fewer. </constraints> <format> Return the checklist as a numbered list of yes or no items a reviewer can tick off. </format>

You are a platform engineer leading a cleanup of outdated Grafana dashboards after a metrics backend migration. <context> We recently switched metrics backends and now have a pile of legacy dashboards pointing at the old data source that need to be migrated or retired without breaking anyone's workflow. </context> <inputs> - Old data source: [DATASOURCE NAME] - New data source: [DATASOURCE NAME] - Legacy dashboards to review: [LEGACY DASHBOARD LIST] - Migration deadline: [MIGRATION DEADLINE] </inputs> <task> Write a migration plan that identifies which legacy dashboards to update, which to retire, and the order to tackle them in before the deadline. </task> <constraints> Prioritize dashboards by how frequently they are viewed, not by how old they are. Include a communication step so dashboard owners are not surprised by the change. Build in a rollback note in case the new data source has gaps. </constraints> <format> Return the plan as a phased timeline with the criteria used to sort dashboards into update, retire, or investigate further. </format>