Build triggering on code and schedule events

BuildKite runs pipelines on infrastructure the team controls, coordinating jobs across build agents. A Beam agent triggers a build when a defined event occurs, such as a code push or a scheduled release window, then reads the resulting build status as jobs run. Where the customer has approved a rule, for example re-running a build once after a known flaky step, the agent applies it automatically. Builds that fail for a new or unrecognized reason are left as is and routed to a person, rather than retried repeatedly without understanding why they failed.

Pipeline and job status tracking

A Beam agent reads job-level status across a BuildKite pipeline, tracking which steps passed, failed, or are still running, and how long each step took compared to its usual duration. It can update a status dashboard or notify a channel when a pipeline finishes, and mark a build as blocked if a required step did not complete. When a step fails in a way that does not match a known pattern, or takes far longer than usual, the agent flags it to a person instead of deciding whether to proceed.

Build agent and infrastructure visibility

Since BuildKite pipelines run on infrastructure the customer hosts, a Beam agent can read agent availability and queue depth where the connector and account permissions allow it, checking whether builds are queued because agents are busy or offline. On a schedule, it can notify a person if queue depth stays above an agreed level for too long, since that usually points to a capacity problem. The agent does not provision or restart infrastructure itself. It surfaces the signal so a person can decide on capacity changes.