Schedule icon
Request icon
If icon
Log icon
SlackIncomingWebhook icon
Fail icon

GraphQL synthetic health and resolver canary probe

Run synthetic GraphQL health canary probes every 5 minutes, validate root typename responses, and dispatch urgent Slack alerts on silent resolver errors.

Categories
CloudInfrastructure

Catch silent GraphQL API failures and broken resolver dependencies before users do. Unlike REST endpoints that return explicit 5xx HTTP status codes on server faults, GraphQL gateways frequently return HTTP 200 OK while embedding resolver exceptions, database timeouts, and schema validation failures inside the JSON errors array. Standard HTTP uptime pings mistake these responses for healthy traffic. This blueprint runs a high-frequency synthetic canary probe every 5 minutes using io.kestra.plugin.graphql.Request, asserts that the root __typename resolves cleanly, checks for null error arrays, and trips an automated Slack incident alert and pipeline failure when degradation is detected.

How it works

  1. A Schedule trigger initiates a synthetic health probe every 5 minutes (shipped disabled by default).
  2. Task execute_canary_probe issues a minimal typed query (query SyntheticCanary { __typename }) to the GraphQL endpoint (graphql_endpoint_url) with failOnGraphQLErrors: false and allowFailed: true so error payloads can be inspected.
  3. Task evaluate_canary_health (io.kestra.plugin.core.flow.If) evaluates three criteria: HTTP 200 status code, verified __typename matching expected_typename ('Query'), and absence of any GraphQL error payload:
    • If healthy: Task log_canary_healthy logs clean operational status.
    • If degraded: Task alert_canary_failure dispatches an urgent Slack alert containing the HTTP status, returned typename, and error message. If inputs.fail_on_unhealthy is enabled, task fail_canary_execution terminates the flow with an error.
  4. Task log_probe_metrics records audit metrics.
  5. Top-level errors handler alerts SRE teams if DNS resolution fails or the gateway drops connections entirely.

What you get

  • Continuous round-trip synthetic health monitoring tailored specifically for GraphQL semantics.
  • Interception of "silent 200 OK" errors where resolvers fail inside successful HTTP responses.
  • Immediate Slack alerting with diagnostic details when schemas fail to parse or backends disconnect.
  • Zero external monitoring agent fees by orchestrating probes directly within Kestra.

Who it's for

  • Site Reliability Engineers (SRE) and Platform teams supporting GraphQL gateways (Apollo Router, Envoy, Yoga, Hasura).
  • Backend engineers maintaining federated subgraphs and microservice resolvers.
  • DevOps engineers configuring synthetic availability alerts and public status page indicators.

Why orchestrate this with Kestra

Standard synthetic monitoring SaaS tools often lack native understanding of GraphQL response payloads or charge high recurring per-check fees. Kestra provides native GraphQL execution via io.kestra.plugin.graphql.Request, secure secret management for API bearer tokens, declarative flow-control logic, and automated multi-channel incident dispatch in plain YAML.

Prerequisites

  • An accessible GraphQL endpoint URL (production, staging, or internal VPC gateway).
  • An API bearer token or secret header if the endpoint requires authentication.
  • A Slack Incoming Webhook URL.

Secrets

  • GRAPHQL_API_TOKEN: Bearer token passed in the Authorization header (can be a dummy string if public).
  • SLACK_WEBHOOK_URL: Slack Incoming Webhook URL used to transmit outage notifications.

Quick start

  1. Store your endpoint access token and Slack webhook in Kestra Secrets (GRAPHQL_API_TOKEN and SLACK_WEBHOOK_URL).
  2. Configure graphql_endpoint_url with your target GraphQL server URL.
  3. Run a manual execution from the Kestra UI to verify that the { __typename } query executes cleanly.
  4. Enable the periodic_canary_schedule trigger to establish 5-minute automated canary sweeps.

How to extend

  • Extend custom_canary_query to query a critical business entity (e.g. viewer { id email } or healthCheck { status }) for deeper synthetic verification.
  • Integrate with PagerDuty or Opsgenie using Kestra notification plugins to page on-call engineers when consecutive canary runs fail.
  • Push probe latency metrics to Prometheus or Datadog to chart API round-trip response times across deployment windows.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.