Monitor TeamCity — and get told why a build failed
Add a Command Line build step to your TeamCity configuration and set a heartbeat watchdog in LastPing. Every build confirms in; a build that fails, queues forever, or never starts — including a server that goes down and can't email you — opens an incident with failure detail. Free for individuals, no monitor cap.
TeamCity can't tell you it's the problem.
Three failure modes are common in TeamCity installations running scheduled builds — and none of them reliably deliver a useful, timely alert through TeamCity's own notification system.
Server down, no notification
Like Jenkins, TeamCity's notification system is part of the server. If the server host crashes, runs out of disk, or is taken offline for maintenance, the build notifications stop with it. The watchdog must live outside the system it's watching.
All agents disconnected
A scheduled build trigger fires, but all agents compatible with the build configuration are disconnected or at capacity. TeamCity queues the build indefinitely. No build-queued-too-long alert fires by default.
Schedule trigger misconfigured or disabled
A VCS trigger failure, a disabled build configuration, or a mis-configured schedule trigger silently stops builds from firing. TeamCity's notification rules only alert on build events, not on the absence of them.
TeamCity's built-in notification rules (Notification Rules under your profile, or the Notification plugin) send alerts on build result events — but they can't send an alert when no build event happens at all. The external watchdog pattern closes this gap: it expects a build-completion signal at your scheduled cadence and opens an incident when that signal doesn't arrive.
Setup: one build step, about five minutes
Uses TeamCity's built-in Command Line runner. No plugin installation, no Kotlin DSL change required for UI-configured builds.
Create a heartbeat monitor in LastPing
In the console, create a monitor, choose Heartbeat, and set the period to match your TeamCity schedule trigger (e.g. daily, hourly). Add a reasonable grace window. Copy the ping URL.
Add a Command Line step at the top of the build
In Build Configuration → Build Steps → Add build step, choose Command Line. Place it first. In the Custom script field, add the start ping. This arms overrun detection for the full build chain.
Add a final Command Line step (always execute)
Add a Command Line step at the end of the build. Under Step execution policy, choose Always, even if build stop command was issued. This step runs regardless of build outcome and branches on the TeamCity system parameter.
Done — every build now reports in
LastPing receives the start and completion pings. A build that never starts — server down, all agents offline, trigger disabled — is caught when the expected completion ping doesn't arrive within the grace window. Alerts go to email, Telegram, Slack, Discord, or a signed webhook.
What this catches
The same durable detection engine as LastPing's cron monitoring — deadlines live in the database, so a restart never misses a due check.
- Failed builds — the always-execute step fires and POSTs the project name, build type, and build number to the incident.
- Hung builds — a build that reports a start ping but never completes; the missing completion ping opens an incident after the grace window.
- Builds that never start — server down, all agents offline, trigger disabled. No ping in the expected window → incident.
- Recovery — the next successful completion ping closes the incident and sends a recovery notice automatically.
- Flap protection — a build that fails and immediately recovers within the damping window doesn't page you.
This is the same external-watchdog concept as Jenkins monitoring — because both systems share the same structural problem: the notifier lives in the process that might be down. For systems with native CI webhook support in LastPing, see GitHub Actions and GitLab CI. AI agents can self-register their own monitors via MCP.
Questions people ask
Front-loaded answers — the most important fact first.
-
How do I get alerted when a TeamCity build fails?
Add a Command Line build step with step execution policy: always execute that branches on
%system.teamcity.build.lastStatus%to POST failure detail to LastPing's/failendpoint, or send a success ping. Add a heartbeat monitor with your schedule trigger's cadence. Free, no monitor cap. -
How do I know if the TeamCity server is down?
TeamCity cannot send you a notification that it is down — the notification system is part of the server process. A LastPing heartbeat watchdog outside TeamCity expects a completion ping at your scheduled cadence. A server that goes down, runs out of disk, or is taken offline for maintenance is caught as a missing signal when the grace window passes.
-
Does TeamCity have a built-in queued-too-long alert?
No. TeamCity's notification rules alert on build events (started, finished, failed) — not on the absence of events. A build that queues indefinitely because all agents are offline generates no notification. A LastPing heartbeat monitor catches this as a missing completion ping within the grace window.
-
Can I use the Kotlin DSL instead of the UI?
Yes. The same logic in a Kotlin DSL build step: add a
exec { }step withexecutionMode = BuildStep.ExecutionMode.ALWAYSand a shell script that branches on%system.teamcity.build.lastStatus%to ping LastPing. -
Is this free?
Yes. LastPing is free for individuals with no monitor cap. See vs Healthchecks.io, vs Cronitor, or the roundup of free cron monitoring tools.
Your next silent build failure is already queued.
One build step now beats a post-mortem later. First alert wired up in about five minutes — and LastPing monitors itself the same way.