Skip to main content
Version: 1.0

Webhooks

Tantilium Cloud Runner (TCR) has two genuinely different things that could be called a "webhook," and it's worth being precise about which one you mean, because they run in opposite directions. There is no self-service webhook subscription system (no "register a URL to be notified of any platform event" API) — the platform's actual webhook surface is narrower and more specific than that.

Inbound: your repository notifying Tantilium Cloud Runner​

This is the more common case: a tenant's own Git repository is configured to push a webhook to TCR whenever code is pushed, and TCR uses that to trigger a CI run or a Kaniko build automatically. This is not something you subscribe to through an API call — it's configured the normal way, in your repository host's own webhook settings, pointed at a URL TCR gives you when you register a pipeline or a build config.

  • CI pipeline runs — configuring a pipeline in the Pipelines dashboard gives you a webhook URL ({provider} is github or gitlab) to add to your repository's settings. A push is what starts tracking a real CI run.
  • Automatic image builds — registering a Build Config for auto-rebuild-on-push, documented on the Build Service page, works the same way: TCR gives you a URL, your repository's own webhook settings point at it.

Both accept the provider's standard webhook payload shape and, where a shared secret is configured, verify it using that provider's own signature scheme — nothing TCR-specific to implement on your end.

Outbound: Tantilium Cloud Runner notifying you about an incident​

The one genuine "TCR calls a URL you control" mechanism today is narrower than a general event bus: incident-manager can be configured with a single webhook URL (alongside its Slack/email/PagerDuty notification channels) that receives a POST for exactly three event types — incident.created, incident.updated, and incident.resolved. The request body carries the incident's ID, cluster, title, severity, status, category, namespace, affected service, message, and timestamp as plain JSON, and — when a shared secret is configured — an X-Webhook-Secret header carrying it, for you to verify on receipt.

{
  "event_type": "incident.created",
  "incident_id": "inc-8f2a1c",
  "cluster_id": "kubeopera-prod",
  "title": "Elevated error rate on payments-api",
  "severity": "critical",
  "status": "open",
  "category": "availability",
  "namespace": "payments",
  "affected_service": "payments-api",
  "message": "Error rate exceeded 5% for 5 consecutive minutes",
  "occurred_at": "2026-09-09T14:02:31Z"
}

There's no per-event subscription filtering — a configured URL receives all three event types — and no other resource in the platform (an app deploying, a pipeline run finishing, and so on) currently has an equivalent outbound webhook. If you need to react to one of those events today, the MCP Server tools or polling the relevant REST endpoint are the available options.

Next Steps​