Synthetic Monitoring Check Design Prompt

This prompt is for SREs and platform engineers who need to translate a documented user journey into a structured, machine-actionable synthetic monitoring specification. The ideal user has a clear understanding of the critical path—such as a login flow, checkout process, or API provisioning sequence—and needs to produce a design artifact that can be handed directly to a monitoring platform like Checkly, Datadog Synthetics, or Grafana Cloud. The prompt assumes you already have a flow description, not that you are discovering one. It is a design-time reasoning tool, not a runtime diagnostic.

Use this prompt when you have a written user flow and need a complete check design covering HTTP endpoints, multi-step browser scripts, assertions, timing budgets, and alerting rules. The prompt also validates the proposed design against real user monitoring (RUM) data to identify coverage gaps—for example, flagging a step in the checkout flow that synthetic checks miss but RUM shows as a frequent drop-off point. Required inputs include the user journey steps, target environment URLs, expected response codes or UI states, and any existing RUM data for gap analysis. The output is a structured specification, not a deployed check.

Do not use this prompt for real-time alert threshold tuning or incident response. Those workflows require live telemetry data, not design-time reasoning. Similarly, avoid this prompt if you lack a documented user flow; it will hallucinate plausible but untethered checks. For high-risk financial or healthcare transactions, always route the generated specification through a human review step before deployment to confirm assertions match business rules and compliance requirements. The next section provides the copy-ready prompt template you can adapt with your own flow details.

The prompt below is designed to take a description of a critical user journey and produce a detailed synthetic monitoring specification. It guides the model to think like an SRE, focusing on the endpoints, assertions, frequency, and alerting rules that would catch a degradation before real users are impacted. The output is structured to be directly usable by an observability platform's configuration API or a Terraform module. Replace the square-bracket placeholders with your specific context before use.

markdownCopy
You are a senior Site Reliability Engineer (SRE) designing a synthetic monitoring check for a critical user journey. Your goal is to produce a complete, implementation-ready specification that can be handed off to a platform engineer for automation.

**User Journey to Monitor:**
[JOURNEY_DESCRIPTION]

**Known Service Endpoints and Dependencies:**
[ENDPOINT_LIST]

**Existing Monitoring Context (e.g., RUM gaps, known weak spots):**
[EXISTING_MONITORING_CONTEXT]

**Constraints:**
- [CONSTRAINT_1, e.g., Must use existing Prometheus Blackbox Exporter]
- [CONSTRAINT_2, e.g., Check must run from at least 3 geographic regions]
- [CONSTRAINT_3, e.g., Budget for 10,000 check executions per month]

**Output Specification Schema:**
Generate a JSON object with the following structure:
{
  "check_name": "string",
  "description": "string",
  "target_endpoint": "URL",
  "http_method": "GET/POST/etc.",
  "request_headers": { "key": "value" },
  "request_body": "string or null",
  "steps": [
    {
      "step_name": "string",
      "action": "navigate | click | type | wait | assert",
      "selector": "CSS or XPath selector",
      "value": "string or null",
      "expected_outcome": "string"
    }
  ],
  "assertions": [
    {
      "type": "status_code | response_time_ms | body_contains | json_path | header_match",
      "target": "string",
      "operator": "equals | less_than | contains | matches_regex",
      "expected_value": "string",
      "severity_if_failed": "CRITICAL | WARNING"
    }
  ],
  "execution_config": {
    "frequency_seconds": 60,
    "locations": ["us-east-1", "eu-west-1", "ap-southeast-1"],
    "timeout_ms": 30000,
    "retry_policy": {
      "max_retries": 2,
      "retry_on_status_codes": [500, 502, 503, 504]
    }
  },
  "alerting_rules": [
    {
      "alert_name": "string",
      "condition": "string (e.g., 'failure_rate > 0.05 for 5m')",
      "severity": "P1 | P2 | P3",
      "runbook_url": "URL",
      "notification_channels": ["slack-channel", "pagerduty-service-id"]
    }
  ],
  "rum_gap_analysis": "string (explain what this synthetic check catches that Real User Monitoring might miss, such as login page availability before any user tries to log in)"
}

**Instructions:**
1. Analyze the user journey and break it down into discrete, testable steps.
2. For each step, define a clear assertion that validates functionality, not just HTTP 200 OK. Prefer asserting on specific content or data changes.
3. Design the execution config to balance detection speed with cost, using the provided constraints.
4. Create alerting rules that fire on sustained failure, not transient blips, and link to a placeholder runbook.
5. In the `rum_gap_analysis`, explicitly state what this check provides that passive monitoring cannot.

Generate only the JSON object. Do not include any explanatory text outside the JSON.

To adapt this prompt, replace the placeholders with your specific context. The [JOURNEY_DESCRIPTION] should be a plain-English narrative of the user flow, like "A user logs in, searches for a product, adds it to their cart, and begins checkout." The [ENDPOINT_LIST] should include any known API paths or services involved. The [EXISTING_MONITORING_CONTEXT] is crucial for the gap analysis; mention if you already have RUM on the checkout flow but not on the login service. The [CONSTRAINT] placeholders let you inject real-world limits like tooling standards, geographic requirements, or budget caps. The output is a strict JSON schema, which makes it suitable for direct piping into an automation script or a CI/CD pipeline that provisions monitoring checks. If you are using a browser-based synthetic tool, you may need to add a browser_script field to the schema; this template is designed for API-first checks but can be extended.

The Synthetic Monitoring Check Design Prompt is not a one-off brainstorming tool; it is a specification generator that should be integrated into a reliable, auditable pipeline. The prompt expects structured inputs—a critical user journey description, known endpoints, existing SLOs, and any gaps identified from Real User Monitoring (RUM) data. Before calling the model, your application must assemble these inputs into the [USER_JOURNEY], [ENDPOINTS], [SLO_CONTEXT], and [RUM_GAP_ANALYSIS] placeholders. If any of these inputs are missing, the harness should either abort with a clear error or route the request to a human for clarification, as an underspecified prompt will produce a generic, untrustworthy monitoring specification.

The model's output must be treated as a draft specification, not a deployable artifact. Your harness should parse the generated JSON specification and run a series of automated validators before it reaches a human reviewer. Check that every defined check has a unique check_id, a valid HTTP method, a non-empty set of assertions, and a frequency_seconds that is a positive integer. Validate that the alerting_rules reference valid check_id values and that severity levels match your organization's taxonomy (e.g., SEV1 through SEV5). If the output fails structural validation, use a retry loop with a maximum of 2 attempts, appending the specific validation errors to the prompt as [PREVIOUS_ERRORS] to guide the model toward a conformant output. Log every validation failure and retry attempt for later prompt debugging.

For high-risk user journeys—such as checkout flows, authentication, or API endpoints that trigger financial transactions—the harness must enforce a human-in-the-loop approval gate. After automated validation passes, the draft specification should be written to a review queue (e.g., a dedicated Slack channel, a Jira ticket, or a Git PR) with a diff against the currently deployed synthetic checks. The approval prompt should summarize the proposed changes, highlight any checks that would alert on-call staff, and link to the RUM gap analysis that motivated the change. Only after explicit human approval should the harness push the specification to your synthetic monitoring tool (e.g., Datadog Synthetics, Checkly, or Grafana k6) via its API.

Model choice matters here. This prompt requires strict schema adherence and precise technical reasoning, so prefer a model with strong JSON mode and instruction-following capabilities, such as gpt-4o or claude-3.5-sonnet. Avoid smaller or older models that are prone to hallucinating assertion logic or inventing non-existent endpoints. Set temperature to 0 to minimize variance in specification generation. If your synthetic monitoring tool has a specific configuration schema, provide it as the [OUTPUT_SCHEMA] placeholder and instruct the model to use response_format with json_schema (OpenAI) or tool use with a structured output definition (Anthropic) to enforce the schema at the API level, reducing the need for downstream repair.

Finally, treat this prompt as a living component. When a synthetic check fails in production and the incident review reveals a missing assertion or an incorrect threshold, feed that finding back into the prompt's [RUM_GAP_ANALYSIS] or [CONSTRAINTS] for the next run. Version the prompt template alongside your infrastructure-as-code repository, and run regression tests quarterly by replaying historical user journey descriptions and comparing the generated specifications against the known-good versions that were approved by humans. This closes the loop between observability design and operational learning.