Monitoring Buddy Works CI/CD with Vigilmon

Buddy Works is a CI/CD automation platform known for its visual pipeline editor, Docker-native builds, and tight Git integration. Teams use it to build, test, and deploy applications directly from GitHub, GitLab, or Bitbucket repositories. When the Buddy web app becomes unavailable, a pipeline gets stuck mid-execution due to resource limits, or webhook delivery from your Git provider fails, builds silently stop triggering and deployments halt. Developers pushing commits see no feedback, and on-call engineers get no alert. Vigilmon lets you add external monitoring for Buddy Works availability, pipeline execution health, API responsiveness, and deployment status so you catch CI/CD failures before they become customer incidents.

What You'll Set Up

• Buddy Works web app and API availability monitoring
• Pipeline execution health via webhooks
• Deployment success rate tracking
• SSL certificate monitoring for your Buddy workspace
• Alert routing for CI/CD failures

Prerequisites

• A Buddy Works account (cloud or self-hosted)
• Buddy API token with WORKSPACE, EXECUTION_INFO, and PIPELINE_INFO scopes
• Your Buddy workspace URL (e.g., https://app.buddy.works/your-workspace)
• A free Vigilmon account

Step 1: Monitor the Buddy Works Web App

Buddy's cloud platform handles all build orchestration through its web interface. When the platform is unavailable — planned maintenance, regional outage, or CDN issues — all builds stop triggering and developers cannot monitor running pipelines. Set up uptime monitoring as your baseline:

1. In Vigilmon, click Add Monitor → HTTP/HTTPS.
2. Set the URL to https://app.buddy.works.
3. Set Check interval to 1 minute.
4. Set Timeout to 15 seconds.
5. Under Expected status, confirm 200 is accepted.

For self-hosted Buddy installations, monitor your instance URL directly:

1. Add a second HTTP monitor pointing to https://buddy.your-org.internal.
2. Add keyword check for Buddy in the response body to catch partial outages where the server responds but serves an error page.

Buddy's status page is available at https://status.buddy.works — you can also add an HTTP monitor there with keyword All Systems Operational to track incidents before they affect your workspace.

Step 2: Monitor the Buddy API

Buddy's REST API powers webhook triggers, pipeline management, and deployment automation. When the API becomes slow or unavailable, external integrations — including Slack bots, deployment scripts, and Git webhooks — fail silently. Monitor the API health endpoint directly:

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Set Expected ping interval to 5 minutes.
3. Copy the heartbeat URL (e.g., https://vigilmon.online/heartbeat/abc123).

Create the API health check script:

#!/bin/bash
# /usr/local/bin/buddy-api-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/abc123"
BUDDY_API_URL="https://api.buddy.works"
BUDDY_TOKEN="your-buddy-api-token"
WORKSPACE_DOMAIN="your-workspace"
TIMEOUT=15

# Check workspace accessibility via the API
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
  --max-time "$TIMEOUT" \
  -H "Authorization: Bearer ${BUDDY_TOKEN}" \
  -H "Content-Type: application/json" \
  "${BUDDY_API_URL}/workspaces/${WORKSPACE_DOMAIN}")

if [ "$HTTP_CODE" = "200" ]; then
  echo "Buddy API OK: workspace accessible (HTTP ${HTTP_CODE})"
  curl -s "$HEARTBEAT_URL"
elif [ "$HTTP_CODE" = "401" ]; then
  echo "Buddy API authentication failed — check API token"
  exit 1
else
  echo "Buddy API degraded: HTTP ${HTTP_CODE}"
  exit 1
fi

Install the cron job:

chmod +x /usr/local/bin/buddy-api-check.sh
(crontab -l 2>/dev/null; echo "*/5 * * * * /usr/local/bin/buddy-api-check.sh >> /var/log/buddy-health.log 2>&1") | crontab -

Step 3: Monitor Pipeline Execution Health

Buddy pipelines can fail silently if a trigger condition is never met (e.g., a push webhook that stopped being delivered), if the runner runs out of resources, or if a pipeline is manually paused by a team member. Monitor your critical pipelines for recent successful executions:

#!/bin/bash
# /usr/local/bin/buddy-pipeline-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/def456"
BUDDY_API_URL="https://api.buddy.works"
BUDDY_TOKEN="your-buddy-api-token"
WORKSPACE_DOMAIN="your-workspace"
PROJECT_NAME="your-project-name"
PIPELINE_ID="12345"            # Numeric pipeline ID from Buddy
MAX_HOURS_SINCE_RUN=24         # Alert if no successful run in 24 hours
TIMEOUT=15

# Get recent pipeline executions
EXECUTIONS=$(curl -sf \
  --max-time "$TIMEOUT" \
  -H "Authorization: Bearer ${BUDDY_TOKEN}" \
  -H "Content-Type: application/json" \
  "${BUDDY_API_URL}/workspaces/${WORKSPACE_DOMAIN}/projects/${PROJECT_NAME}/pipelines/${PIPELINE_ID}/executions?per_page=10" 2>/dev/null)

if [ -z "$EXECUTIONS" ]; then
  echo "Could not fetch pipeline executions from Buddy API"
  exit 1
fi

HOURS_SINCE_LAST_SUCCESS=$(echo "$EXECUTIONS" | python3 -c "
import sys, json
from datetime import datetime, timezone

data = json.load(sys.stdin)
executions = data.get('executions', [])

successful = [e for e in executions if e.get('status') == 'SUCCESSFUL']

if not successful:
    print(9999)
    sys.exit(0)

last_success = successful[0]
finish_time = last_success.get('finish_date', '')

if not finish_time:
    print(9999)
    sys.exit(0)

try:
    finished_at = datetime.fromisoformat(finish_time.replace('Z', '+00:00'))
    now = datetime.now(timezone.utc)
    hours = (now - finished_at).total_seconds() / 3600
    print(int(hours))
except:
    print(9999)
" 2>/dev/null || echo 9999)

HOURS_SINCE_LAST_SUCCESS="${HOURS_SINCE_LAST_SUCCESS:-9999}"

if [ "$HOURS_SINCE_LAST_SUCCESS" -le "$MAX_HOURS_SINCE_RUN" ]; then
  echo "Buddy pipeline OK: last success ${HOURS_SINCE_LAST_SUCCESS}h ago"
  curl -s "$HEARTBEAT_URL"
else
  echo "Buddy pipeline stale: no successful run in ${HOURS_SINCE_LAST_SUCCESS}h (threshold: ${MAX_HOURS_SINCE_RUN}h)"
  exit 1
fi

Set the Vigilmon heartbeat interval to match your MAX_HOURS_SINCE_RUN plus a buffer. For a pipeline that runs on every push and expects at least one daily commit, use a 25-hour heartbeat interval.

Step 4: Monitor Active Execution Status

When a long-running Buddy pipeline is in progress, you want to know if it stalls mid-execution rather than completing or failing. A pipeline stuck in "running" state for longer than its historical average indicates a hung step — usually a deployment waiting for a server that never responds, or a test step blocked on a resource lock.

#!/bin/bash
# /usr/local/bin/buddy-execution-status-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/ghi789"
BUDDY_API_URL="https://api.buddy.works"
BUDDY_TOKEN="your-buddy-api-token"
WORKSPACE_DOMAIN="your-workspace"
PROJECT_NAME="your-project-name"
PIPELINE_ID="12345"
MAX_RUNNING_MINUTES=60    # Alert if any execution runs longer than 60 minutes
TIMEOUT=15

# Get current running executions
RUNNING=$(curl -sf \
  --max-time "$TIMEOUT" \
  -H "Authorization: Bearer ${BUDDY_TOKEN}" \
  -H "Content-Type: application/json" \
  "${BUDDY_API_URL}/workspaces/${WORKSPACE_DOMAIN}/projects/${PROJECT_NAME}/pipelines/${PIPELINE_ID}/executions?status=RUNNING&per_page=5" 2>/dev/null)

LONGEST_RUNNING=$(echo "$RUNNING" | python3 -c "
import sys, json
from datetime import datetime, timezone

data = json.load(sys.stdin)
executions = data.get('executions', [])
now = datetime.now(timezone.utc)
max_minutes = 0

for e in executions:
    start = e.get('start_date', '')
    if start:
        try:
            started_at = datetime.fromisoformat(start.replace('Z', '+00:00'))
            minutes = (now - started_at).total_seconds() / 60
            max_minutes = max(max_minutes, minutes)
        except:
            pass

print(int(max_minutes))
" 2>/dev/null || echo 0)

LONGEST_RUNNING="${LONGEST_RUNNING:-0}"

if [ "$LONGEST_RUNNING" -le "$MAX_RUNNING_MINUTES" ]; then
  echo "Buddy execution status OK: longest running ${LONGEST_RUNNING} min"
  curl -s "$HEARTBEAT_URL"
else
  echo "Buddy execution stuck: running for ${LONGEST_RUNNING} min (max: ${MAX_RUNNING_MINUTES} min)"
  exit 1
fi

Run this every 10 minutes with a 70 minute heartbeat interval. A pipeline that consistently exceeds its expected duration usually has a broken step that should be configured with a timeout.

Step 5: Monitor SSL Certificate Expiry

Buddy integrates with external services via HTTPS — your deployment targets, Docker registries, and notification webhooks all require valid SSL certificates. Monitor the certificate for your self-hosted Buddy instance and any critical deployment targets:

1. In Vigilmon, click Add Monitor → SSL Certificate.
2. Set the Domain to buddy.your-org.internal (for self-hosted) or your deployment domain.
3. Set Alert before expiry to 30 days.
4. Repeat for any additional domains Buddy deploys to.

For Buddy cloud users, also monitor your application domains that Buddy deploys to:

# Check SSL expiry for a deployment target domain
DOMAIN="api.your-app.com"
EXPIRY_DAYS_THRESHOLD=30

EXPIRY_DATE=$(echo | openssl s_client -servername "$DOMAIN" \
  -connect "${DOMAIN}:443" 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | \
  cut -d= -f2)

if [ -n "$EXPIRY_DATE" ]; then
  EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s 2>/dev/null || \
    python3 -c "from datetime import datetime; print(int(datetime.strptime('${EXPIRY_DATE}', '%b %d %H:%M:%S %Y %Z').timestamp()))")
  NOW_EPOCH=$(date +%s)
  DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

  if [ "$DAYS_LEFT" -ge "$EXPIRY_DAYS_THRESHOLD" ]; then
    echo "SSL OK: ${DOMAIN} expires in ${DAYS_LEFT} days"
    curl -s "https://vigilmon.online/heartbeat/REPLACE_WITH_SSL_TOKEN"
  else
    echo "SSL expiring soon: ${DOMAIN} expires in ${DAYS_LEFT} days"
    exit 1
  fi
fi

Step 6: Set Up Alert Channels

Configure Vigilmon to route Buddy Works alerts to your engineering team:

1. Go to Alert Channels in Vigilmon.
2. Add a Slack webhook to #deployments — pipeline failures and stuck executions need immediate developer attention.
3. Add PagerDuty for the web app uptime monitor — if Buddy itself is down, all deployments stop.
4. Add email for SSL certificate monitors — these give you weeks of lead time before an outage.
5. Set Consecutive failures before alert to 2 for the API monitor — transient network issues should not page your team.

For Slack notifications that include a direct link to the failed pipeline:

PIPELINE_URL="https://app.buddy.works/${WORKSPACE_DOMAIN}/${PROJECT_NAME}/pipelines/pipeline/${PIPELINE_ID}"
ALERT_MSG=":red_circle: Buddy Works pipeline *${PIPELINE_ID}* has not succeeded in ${HOURS_SINCE_LAST_SUCCESS}h. Check: ${PIPELINE_URL}"

curl -X POST https://hooks.slack.com/services/YOUR/WEBHOOK/URL \
  -H 'Content-type: application/json' \
  --data "{\"text\": \"$ALERT_MSG\", \"channel\": \"#deployments\"}"

Add maintenance windows around Buddy platform updates:

curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "monitor_id": "BUDDY_UPTIME_MONITOR_ID",
    "duration_minutes": 30,
    "reason": "Buddy Works scheduled maintenance window"
  }'

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP monitor (web app) | https://app.buddy.works | Platform outage, regional unavailability | | HTTP monitor (status) | Buddy status page keyword | Incidents before they affect your workspace | | Cron heartbeat (API) | Workspace API endpoint | API degradation, authentication failures | | Cron heartbeat (pipeline health) | Recent execution success | Stale pipelines, broken webhook triggers | | Cron heartbeat (execution status) | Running execution duration | Hung pipeline steps, deployment timeouts | | SSL certificate monitor | Self-hosted or deployment domains | Certificate expiry before it breaks deployments |

Buddy Works is a reliable CI/CD platform, but external monitoring fills the gap between the platform knowing something is wrong and your team knowing. Vigilmon's heartbeat monitors catch the cases that Buddy's own alerts miss — a pipeline that never triggers because the webhook stopped delivering, or a deployment that runs but always fails in a way that doesn't page anyone.

Start monitoring for free at vigilmon.online.