Required Monitoring Configuration Interruption Prompt

This prompt is designed for observability and SRE teams who need a programmatic gate to prevent a service, feature, or configuration change from being deployed without the required monitoring, alerting, and SLO definitions. Its primary job is to act as a pre-deployment auditor: it receives a service definition, deployment manifest, or feature specification and determines if the observability configuration is complete. The ideal user is a platform engineer integrating this check into a CI/CD pipeline, an SRE building an internal developer portal, or an AI reliability engineer wiring it into an autonomous agent's pre-action approval flow. The prompt expects structured input detailing the service and its current monitoring configuration, and it returns a structured pass/fail report with a specific list of missing components.

Do not use this prompt as a general-purpose infrastructure auditor or a real-time anomaly detector. It is not designed to evaluate the quality of monitoring rules, such as whether an alert threshold is tuned correctly or if a dashboard is well-designed. It strictly checks for the presence of required configuration elements. It is also unsuitable for environments where the required monitoring specification is not clearly defined; the prompt relies on a concrete list of required components (metrics, logs, alerts, SLOs) to perform its audit. Using it without a clear specification will lead to inconsistent and unreliable halting decisions.

Before integrating this prompt, ensure you have a well-defined, machine-readable specification of what 'complete monitoring' means for your organization. This could be a checklist of required Prometheus metrics, mandatory log streams, standard alerting rules for critical paths, or a minimum set of SLOs. The prompt's value is in enforcing this policy consistently and preventing silent failures where a service goes live without anyone realizing it's invisible to the operations team. The next step is to copy the prompt template and adapt the [REQUIRED_MONITORING_SPECIFICATION] placeholder to match your internal standards.

This template is designed for observability and SRE teams who need to enforce a pre-deployment gate: no service or feature should proceed to production without verified monitoring coverage. The prompt acts as an automated compliance check, ingesting a service definition, deployment manifest, or feature flag configuration and comparing it against your organization's required observability standards. It produces a structured interruption report that blocks the workflow and tells the responsible engineer exactly which dashboards, alerts, or SLOs are missing.

Below is the copy-ready template. Replace each square-bracket placeholder with your specific inputs. The [SERVICE_DEFINITION] should include the service name, endpoints, dependencies, and any existing monitoring references. [REQUIRED_MONITORING_SPEC] is your organization's policy document listing mandatory observability components (e.g., 'every service must have a latency p99 alert, an error rate SLO, and a CPU saturation dashboard'). [DEPLOYMENT_CONTEXT] provides the environment, region, and change reason. [OUTPUT_SCHEMA] defines the exact JSON structure you expect back, which your pipeline can parse to block or allow the deployment.

textCopy
You are an observability gate checker for a production deployment pipeline. Your job is to audit a service or feature against a required monitoring specification and halt the workflow if any required observability components are missing. Do not proceed with deployment reasoning. Do not suggest workarounds. Only report gaps.

## INPUT

Service Definition:
[SERVICE_DEFINITION]

Required Monitoring Specification:
[REQUIRED_MONITORING_SPEC]

Deployment Context:
[DEPLOYMENT_CONTEXT]

## INSTRUCTIONS

1. Parse the Service Definition to identify the service name, type, critical endpoints, dependencies, and any existing monitoring, alerting, or SLO references already present.
2. Compare the existing observability coverage against every requirement in the Required Monitoring Specification.
3. For each requirement, determine whether it is:
   - SATISFIED: evidence exists in the service definition or linked resources.
   - MISSING: the requirement is not met and no evidence exists.
   - UNCLEAR: partial evidence exists but is insufficient to confirm compliance.
4. If any requirement is MISSING or UNCLEAR, the overall gate status is BLOCKED. If all requirements are SATISFIED, the gate status is PASSED.
5. Generate a structured report following the Output Schema exactly.

## CONSTRAINTS

- Do not invent monitoring configurations that are not present in the input.
- Do not assume defaults or "common practice" fills gaps.
- If a requirement references a specific metric, threshold, or dashboard name, it must be explicitly matched.
- Treat UNCLEAR as BLOCKED. Do not pass ambiguous coverage.
- Do not include deployment advice, remediation steps, or commentary outside the report structure.

## OUTPUT SCHEMA

Return valid JSON matching this structure:

[OUTPUT_SCHEMA]

## EXAMPLES

[EXAMPLES]

To adapt this template, start by defining your [REQUIRED_MONITORING_SPEC] as a version-controlled policy document. This spec should be specific enough that the model can perform exact matching: 'Service must have a Prometheus alert named HighErrorRate with a threshold of 5% over 5 minutes' rather than 'Service must have error alerting.' The [OUTPUT_SCHEMA] should include fields for gate_status, service_name, checked_at, and an array of findings with requirement_id, status, and evidence. The [EXAMPLES] placeholder should contain at least one PASSED and one BLOCKED example to anchor the model's behavior. After copying the template, test it against a known-bad service definition to confirm it blocks correctly, and against a fully compliant one to confirm it does not false-positive. Wire the JSON output into your CI/CD pipeline so that a BLOCKED status prevents the deployment from proceeding and posts the findings array to the responsible team's channel.

This prompt is designed to act as a pre-deployment gate, not a passive advisor. It should be integrated into a CI/CD pipeline or an infrastructure-as-code (IaC) review workflow where it receives a structured representation of a service definition—such as a Kubernetes manifest, Terraform plan, or a service catalog entry—and returns a strict pass/fail decision. The application layer must parse the JSON output and block the pipeline progression if monitoring_complete is false. Do not rely on the model's conversational tone; the harness must enforce the binary outcome.

To wire this in, construct the [SERVICE_DEFINITION] input by extracting relevant fields from your deployment artifacts: service name, exposed endpoints, declared dependencies, resource types, and any existing monitoring annotations. The [REQUIRED_MONITORING_SPEC] should be a static configuration object maintained in your repository, defining mandatory checks like 'all HTTP endpoints must have an SLO', 'all stateful services require disk-usage alerts', or 'every service must link to a runbook'. After the model returns its JSON report, implement a strict validator that checks for the presence of monitoring_complete, blocking_gaps, and severity fields. If the JSON is malformed, retry once with a repair prompt that includes the raw output and the original schema; if it fails again, escalate to a human operator with the raw output attached.

Logging is critical for auditability. Capture the full prompt, the model's raw response, the parsed JSON, and the pipeline decision (proceed/block) as structured logs. For high-risk production environments, route any blocking_gaps with a severity of critical to a human review queue before the pipeline hard-fails. This allows an SRE to override a false positive—for example, when a service legitimately uses a sidecar for metrics collection that the prompt's pattern-matching missed. The harness should provide a manual override mechanism that records the reviewer's identity, timestamp, and justification, feeding that feedback into future prompt iterations to reduce false-positive interruptions.