How to Monitor Kaniko with Vigilmon

Kaniko solves a real security problem in Kubernetes: building container images without mounting the Docker socket or running a privileged container. Instead, it executes each Dockerfile instruction in userspace, then pushes the resulting image to a registry. But Kaniko jobs are ephemeral — they run as Kubernetes pods, complete (or fail), and disappear. Without external monitoring, a broken build pipeline can go unnoticed until a developer notices they've been waiting on a deployment that never arrived. Vigilmon adds the observability layer: heartbeat monitors that prove builds completed, and HTTP monitors for the services those images power.

What You'll Set Up

• Heartbeat monitors triggered at the end of successful Kaniko builds
• HTTP uptime monitors for applications deployed from Kaniko-built images
• Alerts when builds stop completing or deployed services degrade

Prerequisites

• A Kubernetes cluster running Kaniko build jobs (via a CI system, Tekton, Argo Workflows, or raw Jobs)
• Access to modify Kaniko job definitions or pipeline steps
• A free Vigilmon account

Step 1: Monitor Services Powered by Kaniko-Built Images

Kaniko's output is a container image. Those images run services — and those services need uptime monitoring. Add a Vigilmon HTTP monitor for each production service whose image is built by Kaniko:

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the service's health endpoint: https://yourapp.com/health.
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

This ensures that even if Kaniko's image build succeeds but the resulting image has a runtime defect, you'll catch the service going down within the next check interval.

Step 2: Add a Heartbeat Step to Your Kaniko Job

A heartbeat monitor tells Vigilmon "this build completed successfully." If a Kaniko job fails, hangs, or stops being triggered altogether, Vigilmon detects the missing ping and fires an alert.

Create a heartbeat monitor in Vigilmon:

1. Click Add Monitor → Cron Job / Heartbeat.
2. Name it something like Kaniko image build — myapp.
3. Set the expected interval to match how often the build runs (e.g., 1 hour for builds triggered on each commit, 24 hours for nightly builds).
4. Copy the Heartbeat URL.

Option A: Add a sidecar or init container ping step

For Kubernetes Job definitions, add a final step that curls the heartbeat URL after the Kaniko container exits successfully. The cleanest approach is a separate container in the same pod that waits for Kaniko to complete:

# kaniko-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: build-myapp
spec:
  template:
    spec:
      initContainers:
        - name: kaniko
          image: gcr.io/kaniko-project/executor:latest
          args:
            - "--dockerfile=Dockerfile"
            - "--context=git://github.com/yourorg/yourrepo"
            - "--destination=registry.yourorg.com/myapp:latest"
          volumeMounts:
            - name: docker-config
              mountPath: /kaniko/.docker
      containers:
        - name: heartbeat
          image: curlimages/curl:latest
          command:
            - sh
            - -c
            - |
              curl -fsS --retry 3 \
                "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_TOKEN" > /dev/null
              echo "Heartbeat sent to Vigilmon."
      restartPolicy: Never
      volumes:
        - name: docker-config
          secret:
            secretName: registry-credentials
            items:
              - key: .dockerconfigjson
                path: config.json

The initContainers block runs Kaniko first. Only if Kaniko exits with code 0 does Kubernetes advance to the main container, which sends the heartbeat.

Option B: Append a step in your CI/CD pipeline

If Kaniko is invoked from a CI pipeline step (GitLab CI, GitHub Actions, Tekton), add the heartbeat call immediately after the Kaniko step:

# GitLab CI example
build-image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  script:
    - /kaniko/executor
        --context "${CI_PROJECT_DIR}"
        --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
        --destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHORT_SHA}"
    - wget -q "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_TOKEN" -O /dev/null

# GitHub Actions example
- name: Build with Kaniko
  uses: int128/kaniko-action@v1
  with:
    push: true
    tags: registry.yourorg.com/myapp:${{ github.sha }}

- name: Ping Vigilmon heartbeat
  run: |
    curl -fsS --retry 3 \
      "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_TOKEN" > /dev/null

Step 3: Monitor Image Registry Push Success

Kaniko's final act is pushing the built image to a registry. If the push fails (authentication error, registry outage, disk quota exceeded), the job exits non-zero and the heartbeat step never runs — which is exactly what you want.

To additionally verify that the registry itself is reachable, add an HTTP monitor for your registry's health endpoint:

| Registry | Health URL | |---|---| | Docker Hub | https://hub.docker.com | | GitHub Container Registry | https://ghcr.io | | Google Artifact Registry | https://artifactregistry.googleapis.com | | Self-hosted Harbor | https://registry.yourorg.com/api/v2.0/health |

For self-hosted registries like Harbor or Nexus, the health endpoint gives you a clear signal distinct from general internet connectivity.

Step 4: Set Up Alerting

Configure where Vigilmon sends alerts when a build stops completing or a service goes down:

1. Open the heartbeat monitor in Vigilmon → Alerts.
2. Add channels: email, Slack, PagerDuty webhook, or any HTTP endpoint.
3. Set the grace period to interval + 30 minutes so a single slow build doesn't trigger a false alert.

For HTTP service monitors:

1. Alert after: 1 failed check for production services.
2. Recovery notification: enable so you know when a broken service comes back.

Conclusion

Kaniko removes the Docker daemon security risk from your Kubernetes builds, but it introduces its own operational blind spot: ephemeral jobs that silently fail in the middle of a busy cluster. Vigilmon closes that gap — heartbeat monitors prove each build completed on schedule, and HTTP monitors confirm the resulting images are running healthy services. Together they give you the build-to-runtime visibility that Kaniko's daemonless architecture otherwise makes invisible.

Start monitoring your Kaniko build pipeline at vigilmon.online.