Streamwake + Splunk.
Splunk notifications, into the detection surface.
Splunk is Streamwake's fourth inbound ITSM-class source. A vendor-managed relay (Splunk Cloud → Cloud Functions / Lambda / HEC reverse-proxy) POSTs every Splunk Enterprise / Enterprise Security notification into Streamwake's detection surface — the reverse direction from the eleven +X data-vendor catalog. Splunk Enterprise's alert action does not natively sign; the per-tenant routerToken is the seam the relay wires up, with an optional X-Splunk-Signature HMAC envelope on top.
Every incoming event is one of four typed shapes — notable, search, cad, or alert_action— each carrying its own required-field set so the correlator resolves a typed classification against the streaming failure-mode taxonomy and lands in the Streamwake audit trail with a confidence score and any remediation the agent applied. Cross-vendor ±30s anchors surface against the nearest CloudwatchEvidence row on the same incident.
Alert ingestion from Splunk Enterprise / ES into Streamwake's detection surface.
Push, not poll
A vendor-managed relay (Splunk Cloud → Cloud Functions / Lambda / HEC reverse-proxy) POSTs every Splunk alert-action envelope straight to Streamwake. No scheduled job, no polling — incidents land on the savedsearch fire, not the next minute.
Four canonical kinds
Splunk ES nonce + saved searches + CAD + webhook alert actions are the four shapes accepted. Each carries its own typed field set — `notable` flags urgency / severity / owner; `search` carries count; `cad` carries a ticket + geo; `alert_action` carries the triggered alert + app.
Classified on arrival
Every inbound Splunk event runs through the correlator: severity=critical above baseline fires `splunk_severity_critical` (score 0-100), cross-vendor ±30s anchors against the nearest CloudwatchEvidence row, and a typed metric lands back onto the Splunk workspace.
Splunk is the third pushed-into-Streamwake source. See /integrations/inbound for the full list, or jump back to the Streamwake + X catalog for the eleven vendors Streamwake reads FROM.
Webhook standing,
last inbound, polled every five seconds.
The status indicator below reads from /api/v1/splunk-source/status — a per-tenant webhook standing card surfacing the routerToken, the inbound URL, the optional webhookSecret configured flag, and the last inbound stamp.
Organization label,
region, ingest endpoint, optional HMAC.
Save the per-tenant organization label (required), region / org display name / ingest endpoint URL (optional), and an optional HMAC signing secret. When the secret is configured the inbound route HMAC-verifies every request via X-Splunk-Signature: sha256=<hex> on the raw body, with Authorization: Bearer <secret> as a fallback. Leave the secret blank to keep a previously-configured value — the field is wiped from the form on every save.
What a saved search has to emit.
The four shapes Streamwake accepts correspond to the four Splunk webhook kinds. Pick the one that matches your savedsearch trigger template, then build the curl / webhook target so the JSON envelope carries every required field. Required fields are checked server-side; an envelope missing one returns 400 with a typed error envelope.
| Kind | Required fields |
|---|---|
notable | upstreamId, eventTime, searchName, severity |
search | upstreamId, eventTime, searchName, count |
cad | upstreamId, eventTime, searchName, ticketId |
alert_action | upstreamId, eventTime, searchName, app |
- upstreamId
- eventTime
- searchName
- severity
- urgency
- owner
- description
- source
- app
- region
- severitycritical | major | minor | info | unknown. The correlator fires `splunk_severity_critical` on severity===critical above baseline; severity===major over a long-window baseline fires `splunk_severity_major`.
- urgencylow | medium | high (optional). Mirrors the PagerDuty urgency field — flips severity to sev1 on `urgency:"high"` for the same window.
- ownerOwner email/name surfaced on the audit-trail chip inline next to the row.
- source / appSplunk source + app labels — surfaced on the audit-trail chip so the savedsearch owner is identifiable without re-parsing the payload.
- upstreamId
- eventTime
- searchName
- count
- severity
- owner
- description
- source
- app
- region
- countInteger 1-100,000. Number of savedsearch hits inside the rolled window — the correlator fires `splunk_search_burst` when count > SEARCH_HIT_COUNT_THRESHOLD.
- severityOptional. The canonical `search` shape does not require a severity, but supplying one gives the correlator an explicit cross-window baseline.
- upstreamId
- eventTime
- searchName
- ticketId
- severity
- geoCity
- geoCountry
- owner
- description
- source
- app
- region
- ticketIdThe CAD-target ticket id (ServiceNow incident number, custom CAD dispatch id). Surfaced on the audit-trail row as `ticket · <ticketId>`.
- geoCity / geoCountryOptional. Stored verbatim and rendered as a `geo=<city>,<country>` chip on the audit-trail row when present.
- upstreamId
- eventTime
- searchName
- app
- severity
- triggeredAlert
- owner
- description
- source
- region
- appRequired — the canonical `alert_action` shape keys the row to a Splunk app context. The summary line surfaces `app=<app>` so a savedsearch owner can identify the panel that fired.
- triggeredAlertOptional. Free-form trigger name (e.g. "Edge_Origin_Brownout Action"). Surfaced as `triggered=<name>` on the summary.
The full required + optional field set per kind is on SplunkWebhookEnvelopeSchema in @/lib/contracts/splunk — a single discriminated union on kind. Optional fields are stripped server-side; an omitted severity still surfaces the row, just stamped severity: 'unknown'.
Send a canonical severity=critical notable
through the shipped ingest pipeline.
The button below posts a fixture __test_fixture__ notable envelope to /api/v1/splunk-events/test-fixture — the same inbound pipeline a vendor relay would land. The fixture synthesizes a fixture-* upstreamId so a repeat click within the same minute dedupes against itself (a useful smoke signal that dedupe is wired, not a silent double-write).
The synthesized fixture posts a notable envelope with severity: critical, urgency: high, and the canonical Top_KPI_Breach search name — the shape the correlator is tuned to fire above baseline on. The route returns 200 with accepted: true, an eventId, and a deduped flag on a repeat click within the same minute.
Round-trip results surface here. The test fixtures a __test_fixture__ envelope end-to-end against the same /api/v1/splunk-events/inbound pipeline a vendor relay would land.
The four canonical envelopes Streamwake accepts.
The discriminator is kind; pick a tab below and copy the JSON straight into a Splunk webhook test tool. Each shape's required fields are surfaced in the table above; optional fields are surfaced as null in the example so the savedsearch template can drop them when not populated.
?token=<routerToken>{
"kind": "notable",
"upstreamId": "splunk-es-7d29cc41",
"eventTime": "2026-08-24T13:42:11.000Z",
"searchName": "Top_KPI_Breach",
"severity": "critical",
"urgency": "high",
"owner": "ops@example.com",
"description": "Edge-origin p95 latency breached 1.2s on the EU PoP cluster",
"source": "main",
"app": "SA-Investigations",
"region": "us-east-1"
}A real notable,
landed in the Streamwake audit trail.
The shape of what shows up once the Splunk relay is configured: a single inboundnotableevent as the incident's seed, a typed classification against the streaming failure-mode taxonomy, a cross-vendor ±30s anchor against the nearest CloudwatchEvidence row, and a typed streamwake.splunk.notable.remediation.applied metric landing back on the Splunk workspace.
Top_KPI_Breach fired severity=critical on the EU PoP cluster.
- Splunk upstream id
splunk-es-7d29cc41- Streamwake incident
inc_8z29q3kf7- Urgency
- high
- Owner
- ops@example.com
- Audit cuts
- 4 (1 inbound, 3 outbound)
- Signer
- routerToken · HMAC-SHA256 (optional)
- Splunk account
- streamwake-prod (us-east-1)
- inbound · notable (severity=critical)
Splunk Enterprise Security notable — `Top_KPI_Breach` fired severity=critical on the EU PoP cluster; urgency=high.
just now - correlate · splunk_severity_critical (score 92)
Typed classification surfaced as a SplunkIncidentCandidate row on /app/incidents/inc_8z29q3kf7 — paired against the Amazon CloudFront cache_miss_latency_p95_ms row on the same window.
14s later - anchor · ±30s of CloudWatch evidence
Cross-vendor chip surfaces the capturedAt within ±30s of a CloudwatchEvidence row on the same incident — splunk_es + cdn-edge latency fan-out owned separately on the same frame.
14s later - emit · streamwake.splunk.notable.remediation.applied
Typed metric lands back onto the Splunk workspace — the same dashboard panel that fired the notable re-renders the loop-closure metric the moment the fix lands.
5 min later
Inbound push, scoped per tenant. Every Splunk relay envelope arrives as POST /api/v1/splunk-events/inbound?token=<routerToken>; the per-source routerToken resolves the tenant before the route accepts the envelope, and (userId, sourceId, upstreamId) dedupes a retry so a clicked-twice fixture lands once.
Run the Free Stream Check,
see the same audit trail Splunk feeds.
Paste a playback URL into /stream-check — five checks in under a minute, no login. Pair it with the Book-a-demo block below for a guided walkthrough of the four Splunk webhook kinds, the alert / search filter shape, and the HMAC signing convention on your Splunk workspace.
Book a 20-minute walkthrough on your Splunk workspace.
We're happy to walk through the four webhook kinds, the alert / search filter shape, the HMAC signing convention, and the per-source routerToken against a real Splunk Enterprise or Splunk Cloud workspace. Drop your details below and we'll follow up within 1 business day.