Skip to main content
A signal is a normalized event that enters Scrubbe from an internal or external source — a metric spike from Prometheus, an alert from Datadog, a deployment event from GitHub, or any raw event you send via the API. Signals are the raw material of incident detection. Scrubbe’s intelligence layer (Ezra) correlates signals across services, assesses blast radius, and, when patterns match, promotes them into incident tickets automatically.

​
Signal fields

When you ingest a signal, you provide the following fields:
FieldRequiredDescription
nameYesShort label identifying the signal (e.g. "High error rate on payments")
sourceYesOrigin system: PROMETHEUS, DATADOG, GRAFANA, GITHUB, GITLAB, PAGERDUTY, WEBHOOK, MANUAL, or INTERNAL
typeYesCategory of signal: METRIC, ALERT, LOG, TRACE, DEPLOYMENT, CODE_CHANGE, or ANOMALY
severityNoLOW, MEDIUM, or HIGH — defaults to LOW if omitted
descriptionNoLonger explanation of what the signal represents
serviceIdNoID of the service node this signal is associated with
valueNoFree-form JSON payload containing the raw metric or event data
metadataNoAdditional context (e.g. labels, tags, alert rule name)
triggeredAtNoISO 8601 timestamp of when the event occurred — defaults to the current time

​
Ingesting a single signal

POST /api/v1/signals

{
  "name": "High error rate on payments",
  "source": "PROMETHEUS",
  "type": "METRIC",
  "severity": "HIGH",
  "description": "Error rate exceeded 5% for the last 3 minutes.",
  "serviceId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "value": { "errorRate": 0.07, "window": "3m" },
  "metadata": { "alertRule": "payments_error_rate", "labels": { "env": "production" } },
  "triggeredAt": "2026-05-22T14:00:00Z"
}

​
Bulk ingestion

When you need to forward a batch of signals from a monitoring system or replay historical events, use the bulk endpoint. Send an array of signal objects under the signals key: 
POST /api/v1/signals/bulk

{
  "signals": [
    {
      "name": "CPU spike on api-server-1",
      "source": "DATADOG",
      "type": "METRIC",
      "severity": "MEDIUM"
    },
    {
      "name": "Deployment of payments-service v2.4.1",
      "source": "GITHUB",
      "type": "DEPLOYMENT",
      "severity": "LOW"
    }
  ]
}
Duplicate signals are silently skipped, so bulk ingestion is safe to call repeatedly from your pipeline.

​
Signal lifecycle

A signal moves through four states from ingestion to closure:
1

OPEN (active)

A newly ingested signal enters an active state. It is visible in the signal list and is available for correlation by Ezra. SLA and alerting rules evaluate active signals.
2

ACKNOWLEDGED

A team member has reviewed the signal and is aware of it. Acknowledging a signal suppresses repeat notifications but keeps the signal in scope for Ezra’s correlation.
PATCH /api/v1/signals/:id/acknowledge
3

RESOLVED

The condition that produced the signal has cleared. Resolving a signal records a resolvedAt timestamp.
PATCH /api/v1/signals/:id/resolve
You cannot resolve a signal that has already been resolved.
4

SUPPRESSED

The signal is known and expected — no further action or correlation is needed. Suppressed signals are excluded from Ezra’s active pipeline.
PATCH /api/v1/signals/:id/suppress

​
Filtering signals

GET /api/v1/signals accepts query parameters to narrow results:
ParameterDescription
statusFilter by lifecycle state: OPEN, ACKNOWLEDGED, RESOLVED, SUPPRESSED
severityFilter by severity: LOW, MEDIUM, HIGH
sourceFilter by source system (e.g. PROMETHEUS)
typeFilter by signal type (e.g. METRIC)
serviceIdFilter to a specific service node
fromISO 8601 start of the triggeredAt range
toISO 8601 end of the triggeredAt range
limitNumber of results to return (default: 50)
offsetPagination offset

​
Signal stats

GET /api/v1/signals/stats returns a summary of signal activity for your organization: 
{
  "total": 4821,
  "open": 12,
  "acknowledged": 5,
  "resolved": 4790,
  "suppressed": 14,
  "critical": 3,
  "bySeverity": [...],
  "bySource": [...]
}
Use this endpoint to build signal health dashboards or trigger external alerts when active critical signals accumulate.

​
How signals become incidents

When Ezra receives a signal, it runs a four-stage reasoning pipeline: it assesses the situation, hypothesizes a root cause by correlating related signals and recent deployments, estimates blast radius, and selects a remediation option. If a matching playbook exists and guardrails allow, Scrubbe can promote the signal to an incident ticket automatically. If no playbook matches, the signal is promoted to an OPEN incident for your on-call team to handle. The correlated signal IDs appear on the resulting incident ticket in the correlatedSignalIds field, giving you a full trace from raw event to incident.