Workflows and infrastructure

Workflows

The workflows page (/orgs/:customerId/workflows) shows permanently registered workflows listening for events. It displays a filterable table with columns for workflow name, repository, trigger types, last triggered time, next fire time (for scheduled workflows), source repos, and actions.

Each row is expandable to show trigger configuration details. Rows include action controls: a “Run now” button for manual triggering, a toggle switch to enable/disable the workflow, and a delete button with a confirmation modal (optionally cancelling active runs). Stale workflows (no triggers in the last 30 days) show a yellow “Stale” badge. Registry health indicators (version, sync status, last updated) appear above the table.

A global workflow — one whose trigger carries repos:, so it runs on events from other repos in the org — shows a “Global” badge. Its “Source repos” column lists the repos: patterns it matches, exclusions included.

Filters include trigger type, repository, and workflow name, plus a Hide git-only toggle that is on by default. It hides workflows whose every trigger is a git event (push, pull request, tag, and so on), which is what makes the page useful for finding event-driven and scheduled workflows. Global workflows are never hidden by it: their triggers are ordinarily git ones, so hiding them would conceal the workflows with the widest reach in the org.

Infrastructure

The infrastructure page (/orgs/:customerId/infrastructure) provides infrastructure health monitoring. The orchestrator → scaler → agent tree is the canonical list of every orchestrator connected to this org — each top-level row carries a Manage → link into that cluster’s per-cluster views. It has four sections plus a filter:

Filter the orchestrator → scaler → agent tree without leaving the page.

• Search — a case-insensitive substring match across orchestrator, scaler, and agent fields (cluster name, instance ID, role, version, routing keys; scaler name and type; agent ID, hostname, labels, platform, and arch).
• Status and Scaler-type facets — narrow to a connection-health state (connected / unhealthy / stale / orphaned) or a scaler type (container / firecracker / bare-metal / stateful).

A node stays visible if it or any descendant matches, matching branches auto-expand to reveal the hit, and a running count summarizes the result. While a filter is active every scaler’s agents load up front so agent-level matches resolve across collapsed branches; with no filter the tree loads agents lazily on expand.

• Filter — a search box plus Status and Scaler-type facets above the tree. Typing narrows the tree to matching orchestrators, scalers, and agents (a node stays visible if it or any descendant matches), auto-expands branches that match on a descendant, and shows a running result count. While a filter is active, every scaler’s agents are loaded up front so agent-level matches resolve across collapsed branches; with no filter the tree loads agents lazily on expand.

1. Execution metrics — cards showing total runs (24h), success rate, average duration, and active jobs (queued + running). Refreshes every 30 seconds.

2. Infrastructure alerts — banner summarizing any critical or warning alerts from connected orchestrators. Each alert carries a type (zero-agents, capacity, label-gaps, no-raft-leader) and a severity (warning or critical). A severity the page does not recognize is rendered at the critical level, so an unfamiliar alert is never shown as less urgent than it might be.

3. Infrastructure tree — hierarchical view of orchestrators, their scalers, and agents. Refreshes every 10 seconds. Each orchestrator row shows:

   • orchestrator: (bold monospace, left group) — the orchestrator’s cluster instance ID, set via KICI_CLUSTER_INSTANCE_ID env var or auto-generated as a UUID. If no instance ID is set, the first 8 characters of the connection ID are shown here instead.
   • conn: (dimmed monospace, left group) — first 8 characters of the WebSocket connection ID assigned by the Platform relay. Only shown when an explicit instance ID is present.
   • Connection status badge, role badge (coordinator or worker), version badge (left group, after the ID labels)
   • host: badge (right side) — the system hostname of the machine running the orchestrator process
   • Additional badges on the right side: running-as user, CPU count, memory usage, uptime
   • An info popover on the row lists that orchestrator’s registration details. It ends with a Config files block when the orchestrator reports where its own config files live. The block names the env file, the scaler config, and the compose file, each with a copy button. A path the orchestrator did not report gets no row. An offline orchestrator reports none at all, so the block does not appear for it. Neither does a worker peer: it runs on its own host, and its heartbeat carries no config paths. Every path is a host path on the machine that runs the orchestrator, so it may not resolve on yours.

   Each orchestrator lists its scalers (indented at level 1) showing scaler name, type badge (container/firecracker/bare-metal), active/max agent count, and a config info popover. Below each scaler, its agents (indented at level 2) display agent ID, platform/arch, heartbeat age, hostname, running-as user, CPU count, memory, uptime, and version. Labels (both user-defined and auto-generated kici: prefixed) are shown on a separate row beneath scalers and stateful agents, with a tooltip distinguishing user labels from auto labels.

4. Secret backends — health cards for each configured secret backend (e.g. OpenBao), showing connection status with sync and test actions. Allows triggering a manual sync or connectivity test per backend.

Per-cluster views

Click an orchestrator’s Manage → link in the infrastructure tree to drill into that cluster’s per-orch surfaces (security policy, contexts, secrets, DLQ, registrations, global workflows), keyed by cluster name — the human-friendly name set on the orch via kici-admin cluster-name set <name>, or an auto-generated cluster-<6hex> if no operator has renamed it. Different clusters in the same org can have different settings, so the tree row is the entry point that lets you pick which cluster you’re configuring.

Every panel inside this view scopes to the named cluster. Settings shown here come from that orchestrator’s own configuration — a sibling orchestrator in the same org may have a different security policy, different contexts, and different secrets.

When the cluster shows disconnected, the orch is offline and its current state can’t be queried. Most child pages will return 404 in that state; return to the infrastructure page to find a connected cluster.

To rename a cluster, run kici-admin cluster-name set <new> on the orchestrator host and restart the orchestrator so the new name takes effect.