Push Agents¶

Push agents let you monitor services that are unreachable from the public internet — internal databases, services behind a firewall or VPN, Kubernetes workloads — by flipping the monitoring direction: your agent probes the service and posts results to Wanepia. No inbound connections required.

Before deploying an agent, create a push check for the entity in the dashboard or CLI and note the check ID.

Shell script + cron¶

The simplest approach. Drop a script on any host inside your network that can reach the target service, then schedule it with cron.

Postgres reachability¶

#!/usr/bin/env bash
set -euo pipefail

# Set these as environment variables or hard-code for a dedicated host
WANEPIA_TOKEN="${WANEPIA_TOKEN}"
CHECK_ID="${CHECK_ID}"
DB_HOST="${DB_HOST:-localhost}"
DB_PORT="${DB_PORT:-5432}"

start=$(date +%s%3N)

if pg_isready -h "$DB_HOST" -p "$DB_PORT" -q; then
  latency=$(( $(date +%s%3N) - start ))
  payload="{\"success\":true,\"latency_ms\":$latency}"
else
  latency=$(( $(date +%s%3N) - start ))
  payload="{\"success\":false,\"latency_ms\":$latency,\"error_message\":\"pg_isready failed\"}"
fi

curl -sf -X POST "https://api.wanepia.com/v1/checks/$CHECK_ID/results" \
  -H "Authorization: Bearer $WANEPIA_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$payload"

Schedule it with cron (runs every minute):

* * * * * WANEPIA_TOKEN=wnp_... CHECK_ID=abc123 DB_HOST=postgres.internal /usr/local/bin/wanepia-pg-check.sh

Generic HTTP endpoint (private network)¶

Use this when the endpoint is reachable from inside your network but not from the internet:

#!/usr/bin/env bash
set -euo pipefail

WANEPIA_TOKEN="${WANEPIA_TOKEN}"
CHECK_ID="${CHECK_ID}"
TARGET_URL="${TARGET_URL}"

start=$(date +%s%3N)
http_code=$(curl -o /dev/null -s -w "%{http_code}" --max-time 10 "$TARGET_URL" || echo "000")
latency=$(( $(date +%s%3N) - start ))

if [ "$http_code" = "200" ]; then
  payload="{\"success\":true,\"latency_ms\":$latency,\"status_code\":$http_code}"
else
  payload="{\"success\":false,\"latency_ms\":$latency,\"status_code\":$http_code,\"error_message\":\"got HTTP $http_code\"}"
fi

curl -sf -X POST "https://api.wanepia.com/v1/checks/$CHECK_ID/results" \
  -H "Authorization: Bearer $WANEPIA_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$payload"

Docker¶

Run the agent as a Docker container alongside your service. Use environment variables for the token and check ID so the image stays reusable.

# Dockerfile.agent
FROM alpine:3.20
RUN apk add --no-cache curl bash
COPY agent.sh /usr/local/bin/agent.sh
RUN chmod +x /usr/local/bin/agent.sh
CMD ["sh", "-c", "while true; do /usr/local/bin/agent.sh; sleep ${INTERVAL:-60}; done"]

# docker-compose.yml (add alongside your existing services)
services:
  wanepia-agent:
    build:
      context: .
      dockerfile: Dockerfile.agent
    environment:
      WANEPIA_TOKEN: "${WANEPIA_TOKEN}"
      CHECK_ID: "${CHECK_ID}"
      TARGET_URL: "http://my-internal-api:8080/health"
      INTERVAL: "60"
    restart: unless-stopped

Kubernetes CronJob¶

Run the probe as a Kubernetes CronJob so it executes inside the cluster where it can reach private services.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: wanepia-postgres-check
  namespace: monitoring
spec:
  schedule: "* * * * *"    # every minute — match interval_seconds on the check
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: probe
              image: alpine:3.20
              command:
                - sh
                - -c
                - |
                  apk add --no-cache curl postgresql-client -q
                  start=$(date +%s%3N)
                  if pg_isready -h postgres.default.svc.cluster.local -p 5432 -q; then
                    latency=$(( $(date +%s%3N) - start ))
                    payload="{\"success\":true,\"latency_ms\":$latency}"
                  else
                    latency=$(( $(date +%s%3N) - start ))
                    payload="{\"success\":false,\"latency_ms\":$latency,\"error_message\":\"pg_isready failed\"}"
                  fi
                  curl -sf -X POST "https://api.wanepia.com/v1/checks/$CHECK_ID/results" \
                    -H "Authorization: Bearer $WANEPIA_TOKEN" \
                    -H "Content-Type: application/json" \
                    -d "$payload"
              env:
                - name: WANEPIA_TOKEN
                  valueFrom:
                    secretKeyRef:
                      name: wanepia-credentials
                      key: token
                - name: CHECK_ID
                  value: "abc123def456"    # your check ID

Create the secret:

kubectl create secret generic wanepia-credentials \
  --from-literal=token=wnp_... \
  -n monitoring

Reusable image

For multiple checks, build a custom image with your probe logic baked in and parameterize via env vars. This keeps your CronJob manifests concise.

Agent best practices¶

Use a read-only API key for agents. Read-only keys can post check results but cannot modify your catalog. Create one under Settings → API Keys.

Match interval_seconds to your cron schedule. If the cron runs every minute, set interval_seconds: 60 on the check so the staleness threshold (2× interval) reflects actual cadence.

Set failure_threshold: 1 for push checks. Since agents run infrequently, a threshold of 3 would mean 3 missed runs — potentially 3 minutes of real downtime — before an alert fires.

Keep agents close to the target. Run the agent on the same network segment as the service it probes. A failure means "the service is unreachable from this network", which is what you want to know.