NOC automation

Bring monitoring context and approved remediation into the alert without giving arbitrary commands to operators. Every run is tenant- and team-scoped, checked against its integration allowlist, and written to the alert timeline and audit log.

Before you start
  • Configure integrations as a tenant admin.
  • Use one integration per trust boundary or owning team.
  • Keep bridge signing secrets and provider tokens in the dedicated integration fields; API responses mask them.

Google Cloud Monitoring intake

  1. Create the integration

    Open Integrations, add Google Cloud Monitoring, and copy its inbound webhook URL.

  2. Configure a Cloud Monitoring notification channel

    Send the native Cloud Monitoring webhook payload to that URL. OpsPing uses incident.incident_id as the stable lifecycle identity.

  3. Verify the lifecycle

    An open incident creates one alert. Repeated open notifications deduplicate into it. A closed notification resolves the same alert. Critical, error, warning, and info severities map to P1–P4.

Create Integration dialog with Google Cloud Monitoring selected
Google Cloud Monitoring is a dedicated inbound integration type.
Malformed payloads fail closed

A missing incident ID, missing state, or unknown state returns a validation error and creates no partial alert.

Signed action and enrichment bridges

An action bridge lets OpsPing call an internal CIRT, SOAR, or Alertmanager adapter without building provider-specific authority into OpsPing.

  1. Configure the bridge

    Add an Action & Enrichment Bridge with an HTTPS endpoint, signing secret, and comma-separated action allowlist. Typical names are cirt.create-case and alertmanager.silence.

  2. Verify requests

    Compute HMAC-SHA256 over the ASCII Unix-seconds timestamp, a dot, and the exact raw request body. Compare X-OpsPing-Signature with sha256=<lowercase hex digest> using a timing-safe comparison, reject stale X-OpsPing-Timestamp values, and deduplicate the idempotency key supplied in both the JSON body and X-OpsPing-Idempotency-Key.

  3. Return structured context

    Respond with a required status plus optional externalId, absolute url, message, fields, links, and data. The bridge-run record keeps the full structured response. Alert activity includes status, external identifiers and URL, fields, and labeled links.

{
  "version": "1",
  "operation": "action",
  "action": "alertmanager.silence",
  "idempotencyKey": "…",
  "alert": { "id": "…", "priority": "P1", "status": "open" },
  "parameters": { "duration": "30m" }
}

Allowlisted Rundeck jobs

  1. Create a restricted API token

    Give the Rundeck principal access only to jobs that responders may launch.

  2. Configure the allowlist

    Add a Rundeck integration with its HTTPS base URL, API token, and exact comma-separated job UUIDs.

  3. Run from an alert

    Choose Run Rundeck Job, select an allowed job, and provide string-valued options as JSON. OpsPing records the actor, options, execution ID, URL, start time, and returned status. API retries deduplicate only when they reuse the same idempotency key for that alert and run type. A fresh dialog submission creates a new key, so after an ambiguous timeout inspect the recorded run or provider before submitting again.

Run bridge action dialog with an allowlisted Alertmanager silence operation selected
Approved remediation is selected from the integration allowlist and launched from alert detail beside Jira and incident actions.

Safety boundaries