Kubernetes deployments and rollouts are a common source of production incidents. Logging them in Alert24 gives you a change timeline to correlate against alerts. There are several patterns depending on how you manage your deployments.

Option A: Helm post-install/upgrade hook

If you use Helm, add a hook Job that fires after every install or upgrade:

# templates/alert24-notify.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: "{{ .Release.Name }}-alert24-notify"
  annotations:
    "helm.sh/hook": post-install,post-upgrade
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: notify
          image: curlimages/curl:latest
          env:
            - name: ALERT24_API_KEY
              valueFrom:
                secretKeyRef:
                  name: alert24-secret
                  key: api-key
          command:
            - sh
            - -c
            - |
              curl -s -X POST https://app.alert24.net/api/v1/changes \
                -H "Authorization: Bearer $ALERT24_API_KEY" \
                -H "Content-Type: application/json" \
                -d "{
                  \"summary\": \"Helm {{ .Release.Action }}: {{ .Release.Name }} v{{ .Release.Version }}\",
                  \"change_type\": \"deployment\",
                  \"environment\": \"{{ .Values.environment | default \"production\" }}\",
                  \"source\": \"helm\",
                  \"tags\": [\"kubernetes\", \"helm\", \"{{ .Release.Name }}\"]
                }"

Create the secret:

kubectl create secret generic alert24-secret \
  --from-literal=api-key=ak_live_YOUR_KEY \
  -n your-namespace

Option B: kubectl rollout wrapper script

For teams using raw kubectl:

#!/bin/bash
# kubectl-deploy.sh

DEPLOYMENT="$1"
IMAGE="$2"
NAMESPACE="${3:-default}"
API_KEY="${ALERT24_API_KEY}"

# Apply the rollout
kubectl set image deployment/$DEPLOYMENT app=$IMAGE -n $NAMESPACE
kubectl rollout status deployment/$DEPLOYMENT -n $NAMESPACE
EXIT_CODE=$?

if [ $EXIT_CODE -eq 0 ]; then
  curl -s -X POST https://app.alert24.net/api/v1/changes \
    -H "Authorization: Bearer $API_KEY" \
    -H "Content-Type: application/json" \
    -d "{
      \"summary\": \"Rolled out $DEPLOYMENT: $IMAGE\",
      \"change_type\": \"deployment\",
      \"environment\": \"$NAMESPACE\",
      \"source\": \"kubernetes\",
      \"tags\": [\"kubernetes\", \"$DEPLOYMENT\", \"$NAMESPACE\"]
    }"
fi

exit $EXIT_CODE

Usage: ./kubectl-deploy.sh my-app my-image:v1.2.3 production

Option C: Kubernetes event listener (advanced)

For full automation without touching deployment manifests, run a small listener that watches for Deployment events and notifies Alert24:

# event-listener.py
from kubernetes import client, watch
import requests, os

API_KEY = os.environ['ALERT24_API_KEY']
v1 = client.AppsV1Api()
w = watch.Watch()

for event in w.stream(v1.list_deployment_for_all_namespaces):
    obj = event['object']
    if event['type'] == 'MODIFIED':
        conds = obj.status.conditions or []
        available = any(c.type == 'Available' and c.status == 'True' for c in conds)
        if available:
            requests.post(
                'https://app.alert24.net/api/v1/changes',
                headers={'Authorization': f'Bearer {API_KEY}'},
                json={
                    'summary': f"Deployed {obj.metadata.name} in {obj.metadata.namespace}",
                    'change_type': 'deployment',
                    'environment': obj.metadata.namespace,
                    'source': 'kubernetes',
                    'tags': ['kubernetes', obj.metadata.name],
                }
            )

Tips

Option A vs B: Helm hooks are preferred when you use Helm — they fire exactly once per install/upgrade regardless of how many replicas you're rolling. The kubectl wrapper script is simpler for teams without Helm.
rollout status: Always wait for kubectl rollout status before logging to Alert24. If you log immediately after kubectl apply, you'll record the intent to deploy, not the successful completion.
Rollbacks: kubectl rollout undo is a rollback. Detect it and set change_type: 'rollback' and risk_level: 'high' to distinguish rollbacks from normal deploys in Alert24's timeline.