Runtime signals
Turn monitoring alerts and ML release events into evidence automatically.
Post-market monitoring rarely fails on intent, it fails on transfer: the alert sits in Grafana, the release in GitHub Actions, the model in MLflow – and the compliance file stays empty. Event ingestion closes that gap. You configure a source profile per AI system, register the endpoint in your existing tool, and from then on evidence is created where the work already happens.
At a glance
- Included from
- Professional (part of incident management)
- Where in the app
- Open an AI system → Integrations / Events
- Output
- Automatically created monitoring signals, model registry and release entries
- API
- /api/v1/ingestion
Available connectors
Six connectors, three artifact types. The catalogue is retrievable via the API, so you do not have to retype the endpoints.
| Source | Endpoint | Creates |
|---|---|---|
| MLflow | /ingestion/connectors/mlflow/webhook | Model registry entry |
| GitHub Actions | /ingestion/connectors/github-actions/webhook | Release event |
| GitLab CI | /ingestion/connectors/gitlab-ci/webhook | Release event |
| Grafana | /ingestion/connectors/grafana/alerts | Monitoring signal |
| Prometheus | /ingestion/connectors/prometheus/alerts | Monitoring signal |
| Datadog | /ingestion/connectors/datadog/events | Monitoring signal |
Setup – step by step
- 1Open the AI system the signals should belong to. Every source profile belongs to exactly one system.
- 2Create a source profile: source type (e.g. GRAFANA), the name of the source system, and optionally a default severity and default status for created entries.
- 3Set a shared secret and the name of the signature header. Without a secret the signature is not verified – for production sources you should set one.
- 4Register the endpoint from the table above as a webhook target in Grafana, MLflow, GitHub Actions and so on, and configure the signature there with the same secret.
- 5Trigger a test event and check in the event overview that it arrives as "processed".
Event status
Every incoming event is recorded – including the ones that fail. That is the difference between an integration you can trust and one that fails silently.
| Status | Meaning |
|---|---|
| RECEIVED | Accepted, processing under way. |
| PROCESSED | Processed; the created record is linked to the event and reachable directly from the overview. |
| DUPLICATE | The same external event ID arrived again. No second record is created – so duplicate deliveries from your tool are harmless. |
| FAILED | Processing failed, the error text is stored with it. Up to three attempts. |
| DEAD_LETTER | Permanently stuck after three failed attempts. These entries are your worklist. |
What makes ingestion safe
- HMAC-SHA256 signature verification against the stored secret. The header name is configurable; without one, x-simpleact-signature is expected.
- Duplicate detection via the external event ID – a redelivered event does not create a second piece of evidence.
- Replay on demand: a failed event can be processed again. Events already processed or flagged as duplicates are refused rather than producing a second record.
- The shared secret is never returned. The API only reports whether one is set.
- Every ingestion lands in the audit trail – recorded as a machine change, not as a person’s action.
Usable without a connector too
Besides the six connectors there are generic endpoints for monitoring signals, model registry entries and release events. If your tool is not on the list, post directly to those – you do not need a ready-made connector, just a system that can make an HTTP call.