WordPressのエラー送信が止まったときの点検手順：error_get_last()の上書きとWP-CLI疎通確認新着!!
WordPress から外部のログ集約サービスへエラーを送る仕組みを運用していると、「ある日を境に記録が止まった」という場面に出会います。
ジョブキューの孤児エントリで13日間止まった同期を防ぐ: GCの定期実行と「止まり続けた時間」の監視新着!!
ジョブキューの「実行中」エントリは、ワーカーが crash すると完了にも再投入にも進めず、そのまま残ります。
Woodpecker CIで特定リポジトリだけpipelineが生成されない原因はforge timeoutだった新着!!
セルフホストのWoodpecker CIを運用していると、「特定のリポジトリだけ、pushしてもpipelineが生成されない」という症状に出会うことがあります。
エラー Issue を Claude Code Routine で自動調査する：GitHub Actions から1回だけ叩く薄い設計新着!!
エラー監視基盤が AI で分類して GitHub Issue を起票してくれても、原因調査は結局人間の仕事として残ります。
GitHub Actionsの課金を削る：5秒で終わるjobを減らす「受付job skip」設計と安全に省略するコツ新着!!
GitHub Actions の hosted runner は、5〜8秒で終わる job でも **1 job あたり1分に切り上げて課金**されます。
お気に入りボタンをトグル化する：disabled設計の落とし穴新着!!
お気に入り（いいね・ブックマーク）ボタンは、追加だけを実装して「解除」の導線を作り忘れやすい部品です。オンならdisabledにする設計が解除の経路を奪い、recordIdの保持漏れやバージョン切替時の状態引き継ぎ、モックテストでは拾えない回帰も起こります。
cron監視の「どれか1本成功すればOK」をやめる：ジョブごとの死活監視を周期クラスで設計する新着!!
定期ジョブの監視を「直近24時間に1件でも成功していれば green」で済ませていませんか。cron式から周期クラスを自動推定し、ジョブごとに適切な期間で成功を評価、失敗原因まで分類するper-cronヘルスチェックの設計を解説します。
ON CONFLICT DO NOTHINGの排他制御は「一度きり」にしか効かない: TTL付きUPSERTで直す
`INSERT ... ON CONFLICT DO NOTHING` による排他制御は、TTL付きキャッシュと組み合わせると「一度きりのイベント」にしか効かず、キャッシュ切れ後の再実行で永遠に失敗し続ける落とし穴がある。この記事では、実運用で踏んだその問題と、TTLを条件にした条件付きUPSERTによる解決策をコード例とともに解説します。
CIの成功判定で「わからない」を握りつぶさない設計
自前のCIディスパッチャやデプロイスクリプトを書いていると、「このジョブは成功と名乗ってよいか」を複数の条件から判定する処理が必ず出てきます。
エラーメッセージの文字列判定をやめて、AppErrorに一本化する
エラーメッセージの文言でHTTPステータスを判定する実装は壊れやすいです。code・status・userMessageを持つAppErrorへ一本化し、未分類の例外はfail closedで500に倒し、throw new ErrorをCIで検知する対策を紹介します。