Receive Alerts as CloudEvents

Create a cloudevent_http notification channel in YipYap pointing at your Knative Broker’s ingress URL. YipYap emits a CloudEvent every time an alert changes state, a monitor transitions, or a maintenance window starts or ends, your Triggers filter them from there.

1. Create the CloudEvents channel in YipYap

Go to Settings → Notification Channels → New Channel.
Choose CloudEvents (Knative) as the type.
Fill in:

Field	Example	Notes
Sink URL	`https://broker-ingress.knative-eventing.svc.cluster.local/my-ns/default`	Your Broker’s `.status.address.url`. Must be HTTPS (except localhost).
HTTP Mode	`Binary`	Binary is more filterable at the Broker level. Choose `Structured` if your consumers prefer the full envelope in the body.
Event Types Filter	`["run.yipyap.alert.*"]`	JSON array of globs over `ce.type`. Leave empty for all events.
CloudEvent Overrides	`{"environment": "prod"}`	Extension attributes added to every outbound event. Useful for tagging by environment, region, etc.

Assign the channel to an escalation policy or monitor so YipYap routes alerts to it.

2. Create a Broker (if you don’t have one)

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: default
  namespace: my-ns
spec:
  config:
    apiVersion: v1
    kind: ConfigMap
    name: config-br-default-channel
    namespace: knative-eventing

Apply with kubectl apply -f broker.yaml, then get the ingress URL:

kubectl -n my-ns get broker default -o jsonpath='{.status.address.url}'

Paste that URL into the Sink URL field above.

3. Filter alerts with a Trigger

Route critical alerts to a pager service:

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: yipyap-critical
  namespace: my-ns
spec:
  broker: default
  filter:
    attributes:
      type: run.yipyap.alert.fired.v1
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: pager-handler

The Trigger filters on the binary-mode ce-type header, so no body parsing is required, it’s fast, and it works for any CloudEvents-compatible consumer.

4. Fan out by severity

Multiple Triggers on the same Broker let you route by any CloudEvent attribute:

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: yipyap-monitor-down
  namespace: my-ns
spec:
  broker: default
  filter:
    attributes:
      type: run.yipyap.monitor.down.v1
  subscriber:
    uri: https://oncall.example.com/monitor-down-handler

5. Verify delivery

The easiest sanity check: deploy the Knative-provided event_display service as a consumer, fire a test alert in YipYap, and tail its logs.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: event-display
  namespace: my-ns
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-releases/knative.dev/eventing/cmd/event_display

Then fire an alert from the YipYap UI (any monitor’s Test button works) and kubectl logs -n my-ns deployment/event-display-... --tail=50.