CloudEvent Catalog

Every type follows reverse-DNS naming under run.yipyap and ends in .v1. Schemas are JSON Schema 2020-12 and served at https://console.yipyap.run/schemas/cloudevents/{type}.json.

Outbound (yipyap emits)

All outbound events share the envelope:

specversion, "1.0"
id, ULID, globally unique
source, https://console.yipyap.run/orgs/{org_id} (org-scoped) or https://console.yipyap.run/orgs/{org_id}/monitors/{monitor_id} (monitor-scoped)
type, one of the values below
subject, see per-type table
time, RFC 3339
data, per-type payload, application/json

Alert lifecycle

type	subject	`data` fields
`run.yipyap.alert.fired.v1`	`alert/{alert_id}`	`alert_id, monitor_id, severity (info\|warning\|critical), reason, fired_at`
`run.yipyap.alert.acknowledged.v1`	`alert/{alert_id}`	`alert_id, monitor_id, acked_by, acked_at`
`run.yipyap.alert.resolved.v1`	`alert/{alert_id}`	`alert_id, monitor_id, resolved_by?, resolved_at`
`run.yipyap.alert.escalated.v1`	`alert/{alert_id}`	`alert_id, monitor_id, step_index, to_channel, escalated_at`

Monitor state

type	subject	`data` fields
`run.yipyap.monitor.up.v1`	`monitor/{monitor_id}`	`monitor_id, check_id, latency_ms?, checked_at`
`run.yipyap.monitor.down.v1`	`monitor/{monitor_id}`	`monitor_id, check_id, failure_reason, checked_at`
`run.yipyap.monitor.degraded.v1`	`monitor/{monitor_id}`	`monitor_id, check_id, reason, checked_at`
`run.yipyap.monitor.heartbeat_missed.v1`	`monitor/{monitor_id}`	`monitor_id, expected_by, last_seen_at?`

Maintenance windows

type	subject	`data` fields
`run.yipyap.maintenance.started.v1`	`maintenance/{window_id}`	`window_id, monitors[] (empty=org-wide), started_at, scheduled_end?`
`run.yipyap.maintenance.ended.v1`	`maintenance/{window_id}`	`window_id, ended_at, ended_early?`

Reply events (sink to yipyap)

Every outbound delivery is an opportunity for your sink to reply with a CloudEvent that annotates the alert’s timeline. Replies travel in the HTTP response body of the outbound POST, no separate inbound endpoint, no separate auth.

Each reply must carry a ce_alertref extension attribute equal to the outbound event’s id. Unknown or expired alertrefs are rejected silently (metric’d, not surfaced).

type	`data` shape	Timeline effect
`run.yipyap.reply.alert.claimed.v1`	`{alert_id, who, claimed_at, note?}`	”Claimed by {who}” pill + optional note body
`run.yipyap.reply.alert.enriched.v1`	`{alert_id, attachments: [{label, href?, preview?, kind?}]}`	”Context added ({n} attachments)” pill + link list
`run.yipyap.reply.alert.linked.v1`	`{alert_id, kind, id, url?, title?}`	”Linked to {kind}: {title}” pill + outbound link

Allowed kind values for linked: jira, pagerduty, slack_thread, github_issue, gitlab_issue, linear, servicenow, other.

Reply handling is per-channel opt-in, configure under Settings → Notification Channels → (your CloudEvents channel) → Accepted Replies. Unchecked types are silently dropped.

Inbound (yipyap accepts)

type	`data` shape	Effect
`run.yipyap.ingest.heartbeat.v1`	`{note?: string}`	Records an `UP` check; `note` attached as metadata.
`run.yipyap.ingest.status.v1`	`{status: up\|down\|degraded, message?: string}`	Records a check with the declared status.

Inbound CloudEvents hit POST /api/v1/cloudevents/ingest/{integration-key}. Binary, structured, and batched modes supported. Idempotent within 24h on the CloudEvent id.

Versioning

Additive changes (new optional data field) do not bump the type version.
Breaking changes bump to .v2 alongside continued emission of .v1 through a deprecation window.
Types are never renamed or deleted, only deprecated.

Getting the raw schema

Example: fetch the schema for run.yipyap.alert.fired.v1:

curl https://console.yipyap.run/schemas/cloudevents/run.yipyap.alert.fired.v1.json

Use these schemas to drive validation on your Knative consumers, the same schema YipYap uses internally is authoritative.