Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.scrubbe.com/llms.txt

Use this file to discover all available pages before exploring further.

Signals are the raw alert events that flow into Scrubbe from monitoring tools, APM platforms, and custom integrations. The Signals API lets you ingest signals programmatically — one at a time or in bulk — query their current state, and drive lifecycle transitions: acknowledge, resolve, or suppress. Scrubbe’s intelligence layer continuously correlates open signals to surface incidents and reduce alert noise, so the quality of your signal data directly affects the accuracy of incident detection.
All endpoints require Authorization: Bearer <token>. For external monitoring systems sending signals via server-to-server calls, you may also use X-API-Key: <key> instead of a Bearer token.
Base path: https://your-api-domain.com/api/v1/signals

​
List signals

Returns a paginated list of signals ordered by received time descending. Filter by severity, status, or source to narrow results for dashboards and alert queues. GET https://your-api-domain.com/api/v1/signals
​
page
number
default:"1"
Page number.
​
limit
number
default:"20"
Items per page (max 100).
​
status
string
Filter by status: OPEN, ACKNOWLEDGED, RESOLVED, or SUPPRESSED.
​
severity
string
Filter by severity: LOW, MEDIUM, or HIGH.
​
source
string
Filter by signal source (e.g. "prometheus", "datadog").
curl https://your-api-domain.com/api/v1/signals?status=OPEN&severity=HIGH \
  -H "Authorization: Bearer <token>"
​
data
object[]
Array of signal objects.
​
page
number
Current page number.
​
total
number
Total matching signal count.

​
Get signal stats

Returns aggregate counts and trend data for signals in the workspace — total received, status breakdown, and top alerting sources. GET https://your-api-domain.com/api/v1/signals/stats
cURL
curl https://your-api-domain.com/api/v1/signals/stats \
  -H "Authorization: Bearer <token>"
​
total
number
Total signal count.
​
open
number
Signals currently in OPEN state.
​
acknowledged
number
Signals in ACKNOWLEDGED state.
​
resolved
number
Signals in RESOLVED state.
​
suppressed
number
Signals in SUPPRESSED state.
​
topSources
object[]
Top alerting sources by volume.

​
Get a signal

Fetch a single signal by its ID, including its current status and all attached metadata. GET https://your-api-domain.com/api/v1/signals/:id
​
id
string
required
The signal ID.
curl https://your-api-domain.com/api/v1/signals/SIG-20260522-00841 \
  -H "Authorization: Bearer <token>"

​
Ingest a signal

Ingest a single alert signal into Scrubbe. Scrubbe immediately evaluates it against open signals and active correlation rules. POST https://your-api-domain.com/api/v1/signals
​
name
string
required
Short description of the alert condition (e.g. "High error rate on /api/checkout").
​
source
string
required
The originating system (e.g. "prometheus", "datadog", "custom").
​
type
string
Signal type or category, as defined by the source system.
​
severity
string
required
Severity level: LOW, MEDIUM, or HIGH.
​
serviceId
string
Identifier of the affected service in Scrubbe.
​
value
number
The metric value that triggered the alert (e.g. 0.23 for a 23% error rate).
​
metadata
object
Arbitrary key-value metadata from the source system (labels, tags, dimensions).
​
triggeredAt
string
ISO 8601 timestamp when the alert fired in the source system. Defaults to the time of ingestion.
curl -X POST https://your-api-domain.com/api/v1/signals \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "High error rate on /api/checkout",
    "source": "prometheus",
    "type": "error_rate",
    "severity": "HIGH",
    "serviceId": "svc-payments",
    "value": 0.23,
    "metadata": { "env": "production", "region": "us-east-1" },
    "triggeredAt": "2026-05-22T14:30:00Z"
  }'
​
id
string
required
Unique signal identifier.
​
status
string
required
Initial status — always OPEN.
​
createdAt
string
required
ISO 8601 ingestion timestamp.

​
Bulk ingest signals

Ingest multiple signals in a single request. Use this for batch ingestion from polling integrations or replay scenarios. Each signal is validated independently; partial failures are reported per item. POST https://your-api-domain.com/api/v1/signals/bulk
​
signals
object[]
required
Array of signal objects. Each follows the same schema as POST /.
Bulk ingestion is limited to 100 signals per request.
curl -X POST https://your-api-domain.com/api/v1/signals/bulk \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "signals": [
      {
        "name": "CPU spike on node-1",
        "source": "prometheus",
        "severity": "HIGH",
        "serviceId": "svc-api",
        "triggeredAt": "2026-05-22T14:29:00Z"
      },
      {
        "name": "CPU spike on node-2",
        "source": "prometheus",
        "severity": "HIGH",
        "serviceId": "svc-api",
        "triggeredAt": "2026-05-22T14:29:05Z"
      }
    ]
  }'
​
accepted
number
Count of signals successfully ingested.
​
rejected
number
Count of signals that failed validation.
​
results
object[]
Per-item results in input array order.

​
Acknowledge a signal

Mark a signal as acknowledged to indicate an engineer is aware of it and investigating. Transitions the signal from OPEN to ACKNOWLEDGED. PATCH https://your-api-domain.com/api/v1/signals/:id/acknowledge
​
id
string
required
The signal ID.
​
note
string
Optional note to record alongside the acknowledgement, such as a ticket reference or on-call engineer name.
curl -X PATCH https://your-api-domain.com/api/v1/signals/SIG-20260522-00841/acknowledge \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{ "note": "Investigating — INC-20260522-0041" }'

​
Resolve a signal

Mark a signal as resolved. If the signal was linked to an incident, the incident is not automatically resolved — resolve it separately via the Incidents API. PATCH https://your-api-domain.com/api/v1/signals/:id/resolve
​
id
string
required
The signal ID.
​
note
string
Optional resolution note describing how the condition was cleared.
cURL
curl -X PATCH https://your-api-domain.com/api/v1/signals/SIG-20260522-00841/resolve \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{ "note": "Restarted service — error rate returned to baseline" }'

​
Suppress a signal

Suppress a signal so it no longer contributes to incident correlation or on-call notifications. Useful during known maintenance windows or for muting known-flapping alerts. PATCH https://your-api-domain.com/api/v1/signals/:id/suppress
​
id
string
required
The signal ID.
​
reason
string
Optional reason for suppression (e.g. "maintenance window", "known flap").
Use suppression rather than deletion to preserve signal history for noise analysis and alert tuning.
cURL
curl -X PATCH https://your-api-domain.com/api/v1/signals/SIG-20260522-00841/suppress \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{ "reason": "Scheduled maintenance window" }'

​
Signal field reference

FieldTypeDescription
namestringShort description of the alert condition.
sourcestringOriginating system (e.g. prometheus, datadog).
typestringSignal category as defined by the source.
severitystringLOW, MEDIUM, or HIGH.
serviceIdstringScrubbe service identifier for the affected service.
valuenumberMetric value that triggered the alert.
metadataobjectArbitrary key-value pairs from the source system.
triggeredAtstringISO 8601 timestamp when the alert fired.
StatusMeaning
OPENSignal received, not yet actioned.
ACKNOWLEDGEDAn engineer has seen the signal and is investigating.
RESOLVEDThe alert condition has cleared.
SUPPRESSEDSignal silenced; excluded from correlation and notifications.