Grafana
Connect Grafana alerts to OpsKnight incident ingestion.
What it does
The Grafana adapter accepts inbound webhook events at
/api/integrations/grafana, validates them through its custom handler,
normalizes provider payloads, and submits lifecycle events to the configured
service.
Prerequisites
- An OpsKnight service and enabled integration record.
- The integration identifier and generated integration key.
- Permission to configure webhooks in Grafana.
- A network path from the provider to the OpsKnight web runtime.
Setup and configuration
- In OpsKnight, open Services → your service → Integrations.
- Select Add integration → Grafana, then save the integration.
- Copy the webhook URL and integration key shown by OpsKnight.
- In Grafana, open Alerting → Contact points → Add contact point, choose Webhook, and paste the complete OpsKnight URL.
- Leave the default Grafana/Alertmanager JSON intact. If you configure an OpsKnight signature secret, configure the matching Grafana HMAC signature so
X-Grafana-Signaturecan be verified. - Test the contact point, attach it through a notification policy, then make a test rule fire and return to Normal. Ensure resolved messages are enabled.
Provider console labels can change independently of OpsKnight. Use the webhook or notification configuration area in the provider rather than copying a URL from another service. Treat keys and signature secrets as credentials; never place them in logs or source control.
Authentication and request verification
The endpoint requires the integration identifier.
Signature verification is conditional-when-secret-configured using the
grafana verification contract and headers x-grafana-signature.
The exact payload schema is defined by src/app/api/integrations/grafana/route.ts and src/lib/integrations/grafana.ts.
- Method:
POST - Integration identifier: query parameter
- Integration key transports: none; this route uses the authentication contract above
- Schema:
shared provider schema - Body limit: 1048576 bytes (1 MiB)
- Rate limit: 100 requests per 60 seconds, per integration
Event mapping and incident lifecycle
The adapter emits the lifecycle actions found in its current source:
triggeracknowledgeresolveCorrelation contract: adapter EventPayload.dedup_key. Recovery contract: adapter emits resolve for its recovery state.
Recovery and deduplication
When signature verification runs, delivery identity is read from x-request-id, x-grafana-delivery and protected by the inbound-delivery fence.
Incident convergence still depends on the adapter correlation key. Failed
deliveries are recorded for operational inspection without exposing secrets.
Limits and testing
Per-integration rate limiting protects the ingestion path. Send a representative trigger and recovery pair in a non-production service, verify that one incident is created, and confirm that recovery updates that incident rather than creating another.
Verify the connection
After the test alert, confirm all of the following:
- One incident appears for the selected OpsKnight service.
- The incident source identifies Grafana.
- A repeat event updates or correlates according to the adapter identity.
- A recovery event resolves the correlated incident.
Error reference
400— Invalid request or payload validation failed.401— Configured authentication or signature validation failed.403— Integration is disabled.404— Integration record was not found.413— Payload exceeds the one MiB body limit.429— Per-integration request rate exceeded.500— Provider event processing failed.
Troubleshooting
- Confirm the integration is enabled and belongs to the intended service.
- Verify the integration ID in the URL and rotate any key that may have been exposed.
- Inspect Settings → Integrations → Failures for validation or signature errors.
- Check for
413before changing payload templates and429before retrying rapidly. - Confirm the provider sends a state supported by the event mapping above.
- Preserve the provider delivery identifier and timestamp when escalating.
Related pages
Security
Use HTTPS, rotate exposed keys at both systems, configure signature verification when supported, and restrict provider egress or ingress controls without blocking legitimate retries.
Last updated for v2.0.0
Edit this page on GitHub