しくみ
cronで動かしているバックアップは、失敗しても誰も気づかないまま何日も過ぎることがあります。Slackに結果を送るようにすると、成功・失敗がチャンネルに残り、異常にすぐ気づけます。
この記事の構成は次のとおりです。
- Slackアプリを作り、Incoming Webhook のURLを発行する
- バックアップスクリプトを呼び出し、終了コードで成功・失敗を判断して、Webhook URLへ
curlでPOSTする小さなスクリプトを作る - cronからそのスクリプトを実行する
バックアップスクリプト本体は、WordPressのバックアップを自動化するBashスクリプトで作った /usr/local/bin/wp-backup.sh を例にします。失敗したときに0以外の終了コードで終わるスクリプトであれば、ほかのものでも使えます。
手順1: Incoming WebhookのURLを発行する
Slackの公式ドキュメントにある手順です（2026年10月時点）。
- Slack APIの管理画面（api.slack.com/apps）で、新しいアプリを作成します。名前を付け、通知先のワークスペースを選びます。
- アプリの設定で Incoming Webhooks を開き、Activate Incoming Webhooks をオンにします。
- Add New Webhook to Workspace を押し、投稿先のチャンネルを選んで Authorize を押します。プライベートチャンネルに送る場合は、自分がそのチャンネルのメンバーである必要があります。
- 設定画面の Webhook URLs for Your Workspace に、
https://hooks.slack.com/services/T…/B…/…の形のURLが表示されます。
このURLを知っていれば誰でもそのチャンネルに投稿できます。パスワードと同じように扱い、Gitリポジトリや公開される場所に置かないでください。
投稿先のチャンネルは、URLを発行したときに選んだものに固定されます。送信するJSONに channel を書いても変更できません。別のチャンネルに送りたい場合は、Webhookをもう1つ発行します。
手順2: 送信できるか試す
サーバーから、テストのメッセージを送ります。
curl -X POST -H 'Content-type: application/json' \
--data '{"text":"バックアップ通知のテスト"}' \
https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX成功すると、ok とだけ返り、チャンネルにメッセージが表示されます。失敗した場合は、HTTPの400・403・404などとともに、invalid_payload（JSONの形が不正）、no_text（text が無い）、channel_is_archived（チャンネルがアーカイブ済み）、no_service（Webhookが無効または削除済み）などの理由が返ります。
手順3: Webhook URLをファイルに保管する
URLをスクリプトに直接書かず、root以外が読めないファイルに分けます。
sudo mkdir -p /etc/wp-backup
sudo nano /etc/wp-backup/slack.env
sudo chmod 600 /etc/wp-backup/slack.env# /etc/wp-backup/slack.env
SLACK_WEBHOOK_URL=https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX手順4: 通知つきで実行するスクリプトを作る
ログの内容には " や改行が含まれることがあり、文字列をそのままJSONに埋め込むと invalid_payload になります。JSONの組み立てには jq を使います。
sudo apt install jq curl/usr/local/bin/wp-backup-notify.sh として保存します。
#!/bin/bash
# /usr/local/bin/wp-backup-notify.sh バックアップを実行して結果を Slack に送る
set -uo pipefail
# shellcheck source=/dev/null
source /etc/wp-backup/slack.env # SLACK_WEBHOOK_URL を読み込む
BACKUP_CMD="/usr/local/bin/wp-backup.sh"
LOG="/var/log/wp-backup.log"
HOST="$(hostname)"
notify() {
local payload
payload="$(jq -n --arg text "$1" '{text: $text}')"
curl -sS --fail --max-time 10 -X POST \
-H 'Content-type: application/json' \
--data "$payload" "$SLACK_WEBHOOK_URL" > /dev/null \
|| echo "$(date '+%F %T') slack notify failed" >> "$LOG"
}
start=$(date +%s)
output="$("$BACKUP_CMD" 2>&1)"
rc=$?
printf '%s\n' "$output" >> "$LOG"
elapsed=$(( $(date +%s) - start ))
if [ "$rc" -eq 0 ]; then
notify ":white_check_mark: ${HOST}: WordPressのバックアップ成功（${elapsed}秒）
$(printf '%s\n' "$output" | tail -n 1)"
else
notify ":x: ${HOST}: WordPressのバックアップ失敗（終了コード ${rc}）
$(printf '%s\n' "$output" | tail -n 10)"
fi
exit "$rc"sudo chmod 700 /usr/local/bin/wp-backup-notify.sh
sudo /usr/local/bin/wp-backup-notify.shポイント
- このスクリプトでは
set -eを使っていません。バックアップが失敗しても途中で止まらず、失敗の通知まで届けるためです。 - 成功時は最後の1行、失敗時は最後の10行をメッセージに入れます。失敗の原因（ディスク容量不足、データベースに接続できないなど）がSlack上でわかります。
curl --failは、SlackがHTTPのエラーを返したときに失敗として扱います。通知自体の失敗はログに残します。--max-time 10で、Slackへの接続が詰まってもスクリプトが止まり続けないようにしています。- 終了コードはバックアップの結果をそのまま返すので、ほかの監視の仕組みからも成否を判断できます。
手順5: cronから実行する
/etc/cron.d/wp-backup に書きます。バックアップスクリプトを直接呼んでいた行は、通知つきのスクリプトに置き換えます。
15 3 * * * root flock -n /run/wp-backup.lock /usr/local/bin/wp-backup-notify.shログへの追記はスクリプトの中で行うので、cronの行ではリダイレクトしていません。flock -n は、前回の実行が終わっていないときに二重に起動しないためのものです。
運用のヒント
- 成功も通知しておくと、「通知が来ない」こと自体で、cronが動いていない・サーバーが止まっているといった異常に気づけます。失敗だけを送る運用にする場合は、別の監視（外部の死活監視など）と組み合わせます。
- 複数のサイトやサーバーをまとめて管理する場合は、メッセージにホスト名やサイト名を入れておくと見分けやすくなります。
- Webhook URLが漏れた疑いがあるときは、Slackアプリの設定画面でそのWebhookを削除し、新しいURLを発行して
slack.envを差し替えます。 - 通知先のチャンネルをアーカイブすると、
channel_is_archivedで送信できなくなります。
WordPressのPHPエラーをSlackへ送る方法は、WordPressのエラーをSlackに通知する方法で紹介しています。