curlとjqでAPI死活監視 ― HTTPとJSONを分けて安全に確認する

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。内部執筆指示と重複H1を除去し、通信失敗・HTTPエラー・JSON内容不一致を混同しない監視手順へ整理しました。

検証ステータス：✅ bash/curl/jqの一般的な動作に基づきコードレビュー済み／実API未検証

API監視では、curl自体が成功したか、HTTPステータスが期待値か、JSONの業務状態が正常かを別々に判定すると、障害原因を追いやすくなります。

まず試す

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

API_URL="${1:-https://api.example.com/health}"
TMP_BODY=$(mktemp)
trap 'rm -f "$TMP_BODY"' EXIT

http_code=$(curl --silent --show-error --location \
  --connect-timeout 5 --max-time 10 --retry 2 \
  --output "$TMP_BODY" --write-out '%{http_code}' \
  "$API_URL")
curl_rc=$?

if [ "$curl_rc" -ne 0 ]; then
  echo "FAILED: curl rc=$curl_rc" >&2
  exit 1
fi

if [ "$http_code" != "200" ]; then
  echo "FAILED: HTTP $http_code" >&2
  exit 1
fi

if ! jq -e '.status == "UP"' "$TMP_BODY" >/dev/null; then
  echo "FAILED: JSON status is not UP" >&2
  exit 1
fi

echo "SUCCESS: HTTP 200 / status=UP"

ここを見る

• curl_rc：DNS、TLS、接続タイムアウトなど通信層の失敗。
• http_code：APIサーバーが返したHTTP結果。
• jq -e：レスポンスJSONが期待する業務状態か。

1か所変えてみる

.status == "UP" を、自分のAPIの正常条件に合わせて変更します。最初は読み取り専用のhealth endpointで試してください。

仕事で使うなら

認証情報をコマンドラインへ直接書かず、systemdのCredential機能や権限を絞った設定ファイルなど、実行環境に合った秘密情報管理を使います。429や503を再試行する場合はAPI側の仕様とRetry-Afterを優先します。

この記事の更新履歴

• 2026-09-14 追加：curl終了コード・HTTP・JSONを分離した最小監視例を追加しました。
• 2026-09-14 変更：レスポンス末尾へHTTPコードを連結して分割する方式を、一時ファイルと--write-outを使う方式へ変更しました。
• 2026-09-14 削除：内部執筆指示と不要な一時ファイル処理を削除しました。