Your Cluster Called at 3 A.M.: 10 Prompts That Turn ChatGPT Into a DevOps Engineer Who Never Sleeps

Your Cluster Called at 3 A.M.: 10 Prompts That Turn ChatGPT Into a DevOps Engineer Who Never Sleeps

Every DevOps engineer knows the ritual: a PagerDuty alert at 3 a.m., a wall of kubectl output, and a stack trace that looks like a Jackson Pollock painting. The work is 20% architecture and 80% archaeology — digging through logs, YAML, and someone's half-documented Terraform module from 2023.

Here's the thing: LLMs are genuinely good at exactly this kind of archaeology. They don't get tired, they don't forget the kubectl describe pod flags, and they will happily read 800 lines of a CrashLoopBackOff log at any hour. The catch is that a vague prompt like "fix my Kubernetes" gets you vague, sometimes hallucinated answers. The prompt is the runbook.

Below are 10 prompts I've refined for real infrastructure work in 2026 — covering Kubernetes Gateway API, OpenTofu, GitHub Actions/GitLab CI, and OpenTelemetry-based observability. Each one includes what it's for, how to use it, and how to adapt it to your stack. Treat them as templates, not magic spells: the more context you paste (versions, manifests, error text), the less the model invents.

1. The Dockerfile Auditor (and Slimmer)

For: reducing image size, fixing layer caching, and catching security anti-patterns before they hit the registry.

Why it works: the model can compare your Dockerfile against the official Docker best-practices doc (docs.docker.com/build/building/best-practices) and the multi-stage build pattern, then explain each change.

You are a senior DevOps engineer. Review the Dockerfile below.
Context: base image <python:3.12-slim / node:22-alpine / etc.>, production workload, deployed to Kubernetes.
Tasks:
1. Identify layer-cache misses and reorder instructions.
2. Suggest a multi-stage build if applicable.
3. Flag security issues (running as root, secrets in layers, unpinned tags).
4. Estimate size reduction without breaking the build.
Output: a table (issue

| fix | impact) plus the full rewritten Dockerfile with inline comments.
Dockerfile:
<paste here>

Example use: feed it a 40-line Dockerfile where COPY . . sits before RUN pip install -r requirements.txt. It will move the copy, split dependency installation, and add a non-root USER, which alone removes a common CIS benchmark finding.

Adapt: swap the base-image hint and mention your registry (ECR, GHCR, Harbor) so the model avoids suggesting features your registry doesn't support.

2. The CrashLoopBackOff Detective

For: turning a pile of kubectl output into a ranked hypothesis list.

Act as a Kubernetes SRE. A pod is in CrashLoopBackOff.
Here is `kubectl describe pod <name>`:
<paste>
Here are the last 100 log lines:
<paste>
Here is the relevant Deployment/ConfigMap excerpt:
<paste>
Give me:
1. The 3 most likely root causes, ranked, with the specific line of evidence for each.
2. The exact `kubectl` command to confirm each hypothesis.
3. A fix for each, as a diff to the manifest.
Do not guess at values you cannot see; list what information is missing.

Example use: a pod dying with exit code 137 and no logs. The model should connect 137 to OOMKill, point at resources.limits.memory, and hand you kubectl top pod and kubectl get events --sort-by=.lastTimestamp as confirmation steps.

Adapt: the "list what is missing" clause is essential — it stops the model from fabricating a config value it never saw.

3. Gateway API Manifest Generator

For: writing HTTPRoute and Gateway resources without re-reading the spec every time.

Gateway API has largely replaced Ingress in new clusters, but its resource model (GatewayClass → Gateway → HTTPRoute) trips people up. This prompt anchors the model to the real CRDs.

Generate Kubernetes Gateway API v1 resources for this setup:
- One Gateway (namespace: infra) using GatewayClass <name>, listener on 443 with TLS (secret: <tls-secret>).
- HTTPRoute for host <app.example.com> routing /api to service api-svc:8080 and / to web-svc:80.
- Add a path-based redirect from /old to /new (301).
Use only fields defined in the Gateway API v1.1 spec. Comment every non-obvious field. If a feature requires an experimental channel, say so explicitly.

Example use: the output should include parentRefs, matches with path: {type: PathPrefix, value: /api}, and a RequestRedirect filter — real fields from the official spec at gateway-api.sigs.k8s.io.

Adapt: specify your controller (Envoy Gateway, Istio, Cilium) — some fields are implementation-specific, and the model should flag them rather than assume.

4. The OpenTofu Module Scaffolder

For: generating reusable, documented modules in OpenTofu (the MPL-licensed Terraform fork under the Linux Foundation) instead of hand-copying HCL.

Write an OpenTofu module for <AWS S3 bucket with versioning + SSE-KMS / GCP Cloud Run service / etc.>.
Requirements:
- variables.tf with descriptions, types, and sensible defaults.
- main.tf using only providers compatible with OpenTofu 1.x.
- outputs.tf exposing <bucket_arn, service_url>.
- A usage example in README.md.
- Note any Terraform-only features that are NOT available in OpenTofu.
Do not use `terraform`-specific blocks like <feature> unless supported.

Example use: for an S3 module, expect aws_s3_bucket, aws_s3_bucket_versioning, aws_s3_bucket_server_side_encryption_configuration — the separate-resource pattern required since AWS provider v4+, not the deprecated inline blocks.

Adapt: name your provider version constraints. OpenTofu and Terraform diverge on some newer features, so pinning matters.

5. State & Drift Interpreter

For: making sense of tofu plan / terraform plan output that would otherwise take 20 minutes to read.

Here is my `tofu plan` output:
<paste>
Summarize:
1. Every resource being destroyed or replaced (highlight destroy-before-create).
2. Anything that changed outside of my config (drift), with the likely cause.
3. A risk rating (low/medium/high) per change and what to check before applying.
Format as a table. Do not summarize away any `-/+` (replace) operations.

Example use: a plan that unexpectedly replaces a database because a name attribute changed. The model should flag it as high-risk and suggest lifecycle { ignore_changes } or a rename strategy.

Adapt: tell it your backend (S3+DynamoDB, GCS, etc.) so state-locking advice is accurate.

6. GitHub Actions Pipeline Builder

For: a working CI workflow with caching, matrix builds, and least-privilege permissions on the first try.

Create a GitHub Actions workflow (.github/workflows/ci.yml) for a <language> project.
Requirements:
- Trigger on push to main and pull_request.
- Matrix over <versions>.
- Cache dependencies with actions/cache (correct key including lockfile hash).
- Set `permissions:` to least privilege.
- Run lint, test, and build; upload artifacts.
- Pin third-party actions to a commit SHA, not a floating tag.
Explain each job in one line. Use only actions that exist on the GitHub Marketplace.

Example use: the permissions: contents: read block and SHA-pinned actions/checkout are the two details that quietly pass security review.

Adapt: for GitLab CI, change the prompt to .gitlab-ci.yml with stages, cache:key:files, and rules: — the model handles both dialects if you name the platform.

7. The Incident Postmortem Drafter

For: converting a messy incident timeline into a blameless postmortem skeleton within minutes of resolution.

Draft a blameless postmortem from these raw notes:
<timeline, alerts, chat excerpts>
Structure: Summary, Impact (users, duration), Timeline (UTC), Root Cause, Detection, Response, Action Items (owner + due date placeholder).
Keep tone factual, no blame. Mark any fact I did not provide as [UNVERIFIED] instead of inventing it.

Example use: paste Slack timestamps; get a clean timeline. The [UNVERIFIED] tag is the guardrail that keeps the model from writing a confident fiction about why the outage happened.

Adapt: add your SLO definitions so the Impact section maps to error-budget burn.

8. OpenTelemetry Instrumentation Helper

For: adding traces, metrics, and logs without reading the OTel SDK docs for an hour.

Show how to instrument a <Go/Python/Node> service with OpenTelemetry:
- Auto-instrumentation via the OTel Operator or SDK setup.
- A manual span around <function> with attributes.
- Export to an OTLP endpoint (env vars: OTEL_EXPORTER_OTLP_ENDPOINT).
- A Collector config (receivers/processors/exporters) with batching and sampling.
Use current stable semantic conventions. Cite the attribute names exactly.

Example use: the model should produce OTEL_SERVICE_NAME, a TracerProvider with a BatchSpanProcessor, and a Collector YAML with otlp receiver and batch processor — all real components from opentelemetry.io.

Adapt: specify your backend (Tempo, Jaeger, a vendor) so exporter config matches.

9. The RBAC & Secrets Reviewer

For: catching over-broad permissions and leaked secrets in manifests before kubectl apply.

Review these Kubernetes RBAC and Secret manifests:
<paste>
Flag:
1. Any ClusterRole with wildcard verbs/resources or escalation paths.
2. ServiceAccounts bound to more than they need.
3. Secrets stored as plaintext in Git (suggest External Secrets / Sealed Secrets).
4. Missing `automountServiceAccountToken: false` where appropriate.
Output a findings table with severity and a corrected snippet per finding.

Example use: a ClusterRole granting * on * — the model flags it as critical and proposes a scoped Role with get,list,watch on the exact resources.

Adapt: mention your policy engine (Kyverno, OPA Gatekeeper) to get admission-policy snippets instead of just advice.

10. The "Explain This YAML" Onboarding Prompt

For: the new teammate who inherits a 600-line Helm values file and a silent on-call rotation.

Explain this Helm values file / Kustomize overlay to a mid-level engineer new to the team:
<paste>
For each section: what it configures, why it might be set this way, and what breaks if changed. Flag anything that looks like a workaround. Finish with a 5-question checklist they should ask the team before touching it.

Example use: it turns tribal knowledge into a document — the highest-leverage use of an LLM in DevOps, because it costs nothing and saves a senior engineer an hour of explaining.

Adapt: point it at your internal conventions doc so "why it might be set this way" reflects reality, not generic advice.

Quick reference

The pattern across all ten is the same: give the model your real artifacts, constrain it to real specs, and force it to declare what it doesn't know. A prompt that says "list what is missing" or "mark unverified facts" is worth ten that say "be accurate." The model won't replace your judgment at 3 a.m. — but it will read the logs, propose the diff, and hand you a hypothesis before your coffee finishes brewing. Pick two prompts, wire them into your runbooks, and see which one saves you the next night shift.