SlackのIncoming Webhook：外のシステムからチャンネルに通知を送る

公開 2026年10月31日書いた人大林諒

Slack（スラック）のIncoming Webhookは、外のシステムから決まったURLにJSONを送るだけで、Slackのチャンネルにメッセージを出せる仕組みです。サーバー監視の異常、ホームページの問い合わせ、スプレッドシートの更新のような「Slackの外で起きたこと」を、担当が見ているチャンネルに流せます。この記事では、社員20名ほどのWeb制作会社「サンプルデザイン」が #log-サーバー監視 と #log-問い合わせ に通知を流すまでを、Slackアプリの作成から、curlでの送信、Apps Scriptの例、URLの管理、送れないときの確かめ方まで順に書きます。読み終わると、自分の会社の通知を1本作って、担当が替わっても止まらない形で置けるようになります。前提はプロプランのワークスペースで、Slackアプリを作れる権限があることです。

この記事の内容

先に決めること
サンプルデザインで作るWebhookの一覧
Slackアプリを作ってIncoming Webhookを有効にする
curlで送ってみる
JSONの書き方
外のシステムから送る例
Webhook URLの扱い
ワークフロービルダーのWebhookトリガーとの違い
上限と、送れないときの確かめ方
応用
できないことと、その代わり
よく詰まるところ
次にやること

先に決めること

Webhookで足りるか、Slackアプリのbotが要るか

Incoming Webhookは「決まったチャンネルに、決まったアプリの名前で、送りっぱなしにする」ための仕組みです。送ったメッセージを後から消す、スレッドに返信を重ねる、ボタンを押した結果を受け取る、といったことはできません。公式の開発者向けドキュメントにも、Webhookで送ったメッセージは削除できず、削除したいなら chat.postMessage を使うように書かれています。

やりたいこと	Incoming Webhook	Slackアプリのbot（Web API）
1つのチャンネルにお知らせを流す	できる	できる
送り先のチャンネルを送るたびに変える	できない（URLごとに1チャンネル）	できる
送った通知をスレッドにまとめる	返ってくる情報だけではできない	できる
送ったメッセージを後で消す・書き換える	できない	できる
ボタンを押してもらって結果を受け取る	できない	できる
必要な準備	アプリを作ってURLを発行するだけ	スコープ・トークン・受け口のサーバー

サンプルデザインの通知は、サーバー監視の異常、問い合わせの着信、案件の管理表の更新のどれも「見て気づければいい」ものなので、Webhookで足ります。送った通知に対して誰かが対応したかを記録したい、ボタンで「対応する」を押してもらいたい、と思った時点でbotを作る話になります。その場合はSlack APIとbotの作り方の記事で書いています。

1つのURLは1つのチャンネルに結びつく

Webhook URLは発行するときに送り先のチャンネルを1つ選び、そのURLからは他のチャンネルに送れません。公式にも、Webhookは1人のユーザーと1つのチャンネルに結びつき、送るときにチャンネル・名前・アイコンを上書きできないと書かれています。通知先が3つあればURLを3本発行します。1つのSlackアプリの中に複数のURLを作れるので、アプリを通知の種類ごとに作る必要はありません。

アプリを誰の名前で作り、どこに書き残すか

Webhook URLを発行した人がそのURLの持ち主になります。公式は、作った人のアカウントを停止したときにURLがどうなるかまでは書いていません。実際に運用していると、作った人が辞めたあと、誰も設定画面に入れずURLを作り直せない、何の通知かも分からない、という状態になりがちです。サンプルデザインでは、通知用のSlackアプリは総務Eと代表の2人が共同で管理できるようにし、どのURLがどこから呼ばれているかを一覧表にして残します。アプリを共同で管理できる人を足す設定は、開発者向けの設定画面で確かめてください。

通知を流すチャンネルを分ける

自動の通知を人の会話のチャンネルに混ぜると、会話が流れて読めなくなります。サンプルデザインでは自動の通知は log- で始まるチャンネルに集め、人が反応すべきものだけを担当のチャンネルにも出す決まりにしています。#log-サーバー監視 はエンジニア5名と代表、#log-問い合わせ は営業2名とディレクター4名が入ります。チャンネルの名前の付け方はチャンネル設計の記事で書いています。

サンプルデザインで作るWebhookの一覧

送り元	送り先チャンネル	送る内容	送る仕組み
サーバー監視	`#log-サーバー監視`	応答なし・復旧	監視サービスのWebhook送信
問い合わせフォーム（メールで届く）	`#log-問い合わせ`	件名・送信元・受付時刻	GmailをApps Scriptで見て送る
案件の管理表（スプレッドシート）	`#team-direction`	公開日が決まった案件	スプレッドシートのApps Script
手元での動作確認	`#times-エンジニアc`	テスト送信	curl

アプリは「サンプルデザイン通知」という名前で1つ作り、その中にURLを4本発行します。チャンネルに表示される送り主の名前とアイコンはアプリの設定がそのまま使われるので、通知だと一目で分かる名前とアイコンにしておきます。

Slackアプリを作ってIncoming Webhookを有効にする

手順は2026年10月時点の開発者向け設定画面（api.slack.com/apps）です。設定画面は英語表示です。

ブラウザでSlackにログインした状態で https://api.slack.com/apps を開く
アプリを新しく作るボタンを押す（https://api.slack.com/apps?new_app=1 を直接開いても同じ画面になる）
作り方の選択で「Blank app」を選び、「Continue」を押す
「App Name」に サンプルデザイン通知 と入れる
「Workspace」で「サンプルデザイン」を選ぶ
「Create」を押す

api.slack.com/apps の新規作成で「Blank app」を選んだあと、App Name と Workspace を入れたところ

アプリができると、そのアプリの設定画面が開きます。左のメニューから次の順に進みます。

左のメニューで「Incoming Webhooks」を押す
「Activate Incoming Webhooks」のスイッチをオンにする
画面の下にある「Add New Webhook to Workspace」を押す
送り先のチャンネルに #log-サーバー監視 を選ぶ
「Authorize」を押す
Webhookの画面の一覧に、発行されたURLが出る

アプリ設定の「Incoming Webhooks」で「Activate Incoming Webhooks」をオンにし、「Add New Webhook to Workspace」が見えているところ

プライベートチャンネルに送るURLを作るときは、作る人が先にそのチャンネルに入っている必要があります。チャンネルを選ぶ画面に出てこないときは、まずそのチャンネルに参加してから作り直します。

URLは次の形をしています。末尾の英数字が鍵の役目をするので、記事や手順書には伏せて書きます。

https://hooks.slack.com/services/T00000000/B00000000/xxxxxxxxxxxxxxxxxxxxxxxx

2本目以降のURLも同じ「Incoming Webhooks」の画面で「Add New Webhook to Workspace」を押して、チャンネルを変えて発行します。

ワークスペースの設定でアプリのインストールに管理者の承認が要るようにしている場合、許可の画面で承認の依頼になり、すぐにはURLが出ません。承認の設定はセキュリティ設定の記事で書いています。

送り主の名前とアイコンを整える

Webhookで送るメッセージの名前とアイコンは、送るときに変えられません。アプリの設定画面にある表示情報の欄で、アプリ名・アイコン・背景色を決めておきます。アイコンは「通知」と分かる単色のもので十分です。

curlで送ってみる

URLを発行したら、まず手元のパソコンからcurlで送って届くか確かめます。Macのターミナルやエンジニアの作業環境なら、次の1行でテストできます。

curl -X POST \
  -H 'Content-type: application/json' \
  --data '{"text":"テスト送信です。Webhookの設定を確かめています"}' \
  https://hooks.slack.com/services/T00000000/B00000000/xxxxxxxxxxxxxxxxxxxxxxxx

うまくいくと、HTTPの200と、本文に ok だけが返ってきて、選んだチャンネルにメッセージが出ます。失敗したときは本文にエラーの名前が返ってくるので、その名前で後の「送れないときの確かめ方」の表を引きます。

Windowsのコマンドプロンプトではシングルクォートが使えず、--data の中のダブルクォートを \" に書き換える必要があります。テストはMacのターミナルかPowerShellで送るほうが楽です。

curlで送ったテストのメッセージが #times-エンジニアc に「サンプルデザイン通知」の名前で出ているところ

JSONの書き方

textだけで送る

一番簡単なのは text だけを送る形です。text は必須で、入っていないと no_text のエラーになります。改行は \n で入れます。

{
  "text": "問い合わせが届きました\n件名: サイトリニューアルのご相談\n受付: 2026-10-31 10:24"
}

text の中は、Slackの書式（mrkdwn）が使えます。太字は *太字*、斜体は _斜体_、取り消し線は ~取り消し~、コードは ` コード 、引用は行頭に > です。リンクは <https://example.com/|表示する文字>` の形で書くと、URLの代わりに文字が出ます。

`&` `<` `>` を書き換える

< と > はリンクやメンションの印として使われるので、本文にそのまま入れると表示が崩れます。送る前に & を &、< を <、> を > に書き換えます。公式も、この3文字だけを書き換え、文全体をエンコードしないように書いています。メールの送信元は 営業担当 <info@example.com> のように < > を含むので、問い合わせの通知では必ずつまずきます。

メンションを入れる

通知で人を呼ぶときは、名前ではなくIDで書きます。@デザイナーB と文字で書いても通知にはなりません。公式も、ユーザーのメンションを自動で読み取る機能は廃止したと書いています。

呼びたい相手	書き方	IDの調べ方
1人	`<@U0000000000>`	相手のプロフィールのメニューからメンバーIDをコピーする
ユーザーグループ	`<!subteam^S0000000000>`	ユーザーグループのページのURL
チャンネルにいてオンラインの人	`<!here>`	なし
チャンネル全員	`<!channel>`	なし
チャンネルへのリンク	`<#C0000000000>`	チャンネルを開いたときのURLの最後の部分

サーバー監視の通知では、エンジニアのユーザーグループ（@engineer）を呼びます。担当の交代はユーザーグループのメンバーを入れ替えるだけで済み、Webhookの側は直さなくて済みます。<!channel> を自動の通知に入れると、深夜でも全員の通知が鳴り、すぐに誰も見なくなります。自動の通知で使うのは、ユーザーグループか特定の担当1人までにしておきます。

Block Kitで見出しと項目を分ける

項目が多い通知は、Block Kitで見出しと項目を分けると読みやすくなります。blocks を使うときも text は入れておきます。スマホの通知やデスクトップの通知に出る文字は text が使われるので、ここが空だと通知に何も出ません。

{
  "text": "サーバー監視: sample-design.example が応答しません",
  "blocks": [
    {
      "type": "header",
      "text": { "type": "plain_text", "text": "サーバー監視：応答なし" }
    },
    {
      "type": "section",
      "fields": [
        { "type": "mrkdwn", "text": "*対象*\nsample-design.example" },
        { "type": "mrkdwn", "text": "*検知*\n2026-10-31 09:12" }
      ]
    },
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "<!subteam^S0000000000> 確認をお願いします。手順は <https://example.com/runbook|障害時の手順>"
      }
    }
  ]
}

Block Kitで送った監視の通知が見出しと2つの項目に分かれて表示されているところ

Block Kitには公式の上限があります。2026年10月時点で確かめた主なものは次のとおりです。

項目	上限
1つのメッセージのブロック数	50
見出し（header）の文字数	150文字
セクション（section）の `text`	3,000文字
セクションの `fields` の数	10個
`fields` の1つの文字数	2,000文字

組み立てるときは、公式のBlock Kit Builderで見た目を確かめてからJSONを写すと、括弧の閉じ忘れで invalid_payload になるのを防げます。

外のシステムから送る例

サーバー監視から送る

監視サービスの多くは、異常を検知したときに指定したURLへ送る機能を持っています。送るJSONの中身を自分で書ける監視サービスなら、送り先にWebhook URLを入れ、本文を次のようにします。{{host}} のような差し込みの書き方は監視サービスごとに違うので、そのサービスの説明に合わせます。

{
  "text": "サーバー監視: {{host}} が {{status}} になりました（{{time}}）"
}

注意が要るのは、送る中身を変えられず、監視サービスが決めた形のJSONしか送れない場合です。Incoming Webhookは text か blocks が入った形しか受け付けないので、そのまま送ると no_text か invalid_payload で弾かれます。その場合の手は2つあります。1つは、監視サービスにSlack用の連携が用意されていればそちらを使うこと。もう1つは、間にn8nやワークフロービルダーのWebhookトリガーを挟んで、受け取ったJSONから文を組み立て直すことです。

問い合わせフォームのメールから送る

サンプルデザインのホームページの問い合わせは、info@sample-design.example にメールで届きます。Googleドライブに置いたApps Scriptで、まだ通知していない問い合わせメールを5分おきに探し、件名と送信元だけを #log-問い合わせ に送ります。本文はSlackに流さず、Gmailで開いてもらいます。問い合わせの本文には電話番号や住所が入ることがあり、Slackに流すとチャンネルの全員がいつまでも検索できてしまうからです。

// 共通: Slackに送る
function notifySlack(text) {
  const url = PropertiesService.getScriptProperties().getProperty('SLACK_WEBHOOK_URL');
  const res = UrlFetchApp.fetch(url, {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ text: text }),
    muteHttpExceptions: true
  });
  if (res.getResponseCode() !== 200) {
    console.error('Slack送信失敗: ' + res.getResponseCode() + ' ' + res.getContentText());
  }
}

// & < > を書き換える
function esc(s) {
  return String(s).replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;');
}

// 問い合わせメールを探して通知する（時間主導型トリガーで5分おき）
function notifyInquiries() {
  const name = 'slack-notified';
  const label = GmailApp.getUserLabelByName(name) || GmailApp.createLabel(name);
  const threads = GmailApp.search('to:info@sample-design.example -label:slack-notified newer_than:1d');
  threads.forEach(function (thread) {
    const msg = thread.getMessages()[0];
    const text = ':incoming_envelope: 問い合わせが届きました\n'
      + '件名: ' + esc(msg.getSubject()) + '\n'
      + '送信元: ' + esc(msg.getFrom()) + '\n'
      + '受付: ' + Utilities.formatDate(msg.getDate(), 'Asia/Tokyo', 'yyyy-MM-dd HH:mm');
    notifySlack(text);
    thread.addLabel(label);
  });
}

設定の順番は次のとおりです。

問い合わせを受けるアカウントでGoogleドライブを開き、Apps Scriptのプロジェクトを新しく作る
上のコードを貼り付けて保存する
左の「プロジェクトの設定」を開き、「スクリプトプロパティ」に SLACK_WEBHOOK_URL という名前でURLを入れる
エディタで notifyInquiries を選んで1回実行し、GmailとURL呼び出しの許可を出す
左の「トリガー」から、notifyInquiries を「時間主導型」の「分ベースのタイマー」で5分おきに動くように追加する

Apps Scriptの「プロジェクトの設定」で「スクリプトプロパティ」に SLACK_WEBHOOK_URL を入れたところ（値は伏せる）

URLをコードに直接書かずスクリプトプロパティに置くのは、コードを人に見せたり、別のプロジェクトにコピーしたりしたときにURLが一緒に出回らないようにするためです。

スプレッドシートの更新から送る

案件の管理表で「公開日」の列に日付が入ったら、#team-direction に知らせる例です。スプレッドシートの拡張機能からApps Scriptを開いて書きます。上の notifySlack と esc は同じものを置き、スクリプトプロパティにはこのチャンネル用のURLを入れます。

// インストール型トリガー「編集時」で動かす
function onSheetEdit(e) {
  const sheet = e.range.getSheet();
  if (sheet.getName() !== '案件一覧') return;
  if (e.range.getColumn() !== 6 || e.range.getRow() === 1) return; // F列 = 公開日
  if (!e.value) return;
  const row = e.range.getRow();
  const project = sheet.getRange(row, 2).getValue(); // B列 = 案件名
  notifySlack(':calendar: 公開日が決まりました\n' + esc(project) + ' → ' + esc(e.value));
}

ここで多くの人がつまずくのが、関数名を onEdit にして動かそうとすることです。onEdit のような単純トリガーは、認証が必要なサービス（UrlFetchApp など）を使えないため、外に送れません。トリガーの画面から、イベントの種類を「編集時」にしたインストール型のトリガーを追加して、そちらで onSheetEdit を動かします。

Apps Scriptの「トリガー」で、イベントのソース「スプレッドシートから」、イベントの種類「編集時」を選んでいるところ

インストール型のトリガーは、作成した人のアカウントで動きます。追加した人が辞めてアカウントが止まると、通知も止まります。共有のアカウントで作るか、担当が替わるときにトリガーを作り直す手順を一覧表に書いておきます。

Webhook URLの扱い

Webhook URLは、それを知っている人なら誰でもそのチャンネルに投稿できる鍵です。公式も、URLには秘密が含まれていて、漏れた秘密をSlackが探して無効にしていると書いています。公開されたGitHubのリポジトリにURLを書いたまま上げると、ある日突然送れなくなることがあります。

置き場所

置き場所	向くか	理由
Apps Scriptのスクリプトプロパティ	向く	コードと分けて置ける
サーバーの環境変数・設定ファイル（リポジトリの外）	向く	コードと分けて置ける
GitHubのリポジトリのシークレット	向く	ログにも伏せて出る
監視サービスの通知先の設定欄	向く	そのサービスの中だけで使う
コードの中に直接書く	向かない	コピーや公開で一緒に出回る
Slackのチャンネルやスプレッドシートに貼る	向かない	見られる人が多く、残り続ける

サンプルデザインでは、URLそのものは1Passwordのような社内のパスワード管理に入れ、管理の一覧表には「どのアプリの、どのチャンネル向けのURLを、どこに入れたか」だけを書きます。

漏れたとき・作り直すとき

URLが漏れたかもしれないと分かったら、次の順で入れ替えます。

アプリ設定の「Incoming Webhooks」で、同じチャンネルに新しいURLを発行する
送り元（監視サービス・スクリプトプロパティなど）のURLを新しいものに入れ替える
テストで新しいURLから届くことを確かめる
古いURLを削除する
古いURLで送って no_service などのエラーが返ることを確かめる

先に古いURLを消すと、入れ替えるまでの間の通知が落ちます。新しいURLを作ってから古いURLを消す順にします。

ワークフロービルダーのWebhookトリガーとの違い

Slackのワークフロービルダーにも、外からURLに送るとワークフローが始まる「Webhookから」のトリガーがあります。名前が似ていますが、役目が違います。

比べるところ	Incoming Webhook	ワークフロービルダーのWebhookトリガー
作る場所	開発者向けの設定画面でSlackアプリを作る	Slackの中のワークフロービルダー
送ったあとの動き	決まったチャンネルにそのまま投稿される	ワークフローが始まり、投稿・リストへの追加・DMなどの手順が続く
受け取るJSON	`text` か `blocks` の決まった形	自分で決めた項目名のJSON（入れ子は送らない）
送り先	URLごとに1チャンネル	ワークフローの手順で決める
向く使い方	監視・定時の報告など、そのまま流す通知	受け取った値で担当に振る・リストに残すなど、Slackの中で続きがある通知

ワークフロービルダーのWebhookトリガーは、受け取ったJSONの項目をワークフローの変数として使えます。開発者向けの資料にあるWebhookトリガーでは、入れ子のJSONを送るとエラーになると書かれているので、入れ子は送らない形にします。送り元の形を変えられないシステムからの通知を、文に組み立て直して流したいときにも使えます。ワークフロービルダーで作るワークフローは有料プランの機能で、Webhookトリガーの細かい条件（使えるプラン・項目の数の上限）は2026年10月時点のヘルプセンターで確かめてください。作り方はワークフロービルダーの記事で書いています。

上限と、送れないときの確かめ方

上限

公式の上限は、Incoming Webhookで1秒に1件です。短い時間に1件を超えて送ることは許されていますが、続けて送ると制限にかかります。制限を超えると、HTTPの429と、何秒待てば送り直せるかを示す Retry-After が返ってきます。監視のアラートが一斉に出たときや、スプレッドシートで100行をまとめて書き換えたときに起きやすいので、送り元では1件ずつ間をあけるか、まとめて1通にします。

text の長さは、公式では4,000文字までを目安にするよう書かれています。長いログをそのまま流すと読まれないので、要点だけ送ってログの置き場所へのリンクを付けます。

エラーの見方

返ってきたエラー	意味	直し方
`invalid_payload`	JSONの形が壊れている	括弧・カンマ・ダブルクォートを確かめる。Block Kit Builderで組み直す
`no_text`	`text` が入っていない	`text` を入れる。`blocks` だけで送らない
`no_service`	URLが無効・削除済み	一覧にURLがあるか確かめ、無ければ作り直す
`no_active_hooks`	Webhookが無効になっている	「Activate Incoming Webhooks」がオンか確かめる
`channel_is_archived`	送り先がアーカイブ済み	チャンネルを戻すか、新しいチャンネルでURLを作り直す
`channel_not_found`	送り先のチャンネルが無い	チャンネルを消していないか確かめ、作り直す
`action_prohibited`	管理者が投稿を制限している	送り直さず、チャンネルの投稿権限を確かめる
`posting_to_general_channel_denied`	全員のチャンネルへの投稿が制限され、URLを作った人に権限が無い	通知専用のチャンネルに送り先を変える
`too_many_attachments`	添付が100を超えている	件数を減らす
`team_disabled`	ワークスペースが使えない状態	ワークスペースの状態を管理者に確かめる

確かめる順番は、1つ目にcurlで同じURLへ {"text":"test"} を送ること、2つ目に送り元が実際に送っているJSONを記録して見ることです。curlで届くのに送り元から届かないなら、送り元のJSONか送り方（Content-type の指定漏れなど）が原因です。curlでも届かないなら、URLかSlack側の設定が原因です。

アプリ設定の「Incoming Webhooks」の一覧で、URLごとの送り先チャンネルが分かる欄

応用

通知の量を絞る

自動の通知は、増やすより絞るほうが難しくなります。実際に運用していると、復旧の通知・警告レベルの通知・定時の「正常です」の通知まで全部流して、1週間で誰も #log-サーバー監視 を開かなくなる、ということが起きます。異常と復旧だけを流し、警告は1日1回のまとめにすると、通知を見る習慣が残ります。チャンネルの通知設定は、#log- は「メンションのみ」にして、ユーザーグループで呼ばれたときだけ鳴るようにします。

通知をスレッドにまとめたい

同じ障害の「検知」と「復旧」を1つのスレッドにまとめたい、という要望はよく出ます。スレッドに返信するには元のメッセージの ts（メッセージを特定する値）が要りますが、Incoming Webhookは送ったあとに ts を返しません。公式も、ts が要るならEvents APIや conversations.history で取るよう書いています。ここまでやりたくなったら、Webhookをやめて chat.postMessage で送るbotに切り替えるほうが早く済みます。

できないことと、その代わり

できないこと	代わりの手
送るたびにチャンネルを変える	チャンネルごとにURLを発行する。多いならbotの `chat.postMessage`
送り主の名前・アイコンを送るときに変える	アプリを分ける。botなら追加のスコープで変えられる
送ったメッセージを消す・書き換える	botの `chat.postMessage` と `chat.update`
スレッドに返信を重ねる	botで送り、返ってきた `ts` を使う
ボタンを押した結果を受け取る	Slackアプリでインタラクティブな受け口を作る
決まった形以外のJSONを受ける	ワークフロービルダーのWebhookトリガーかn8nで組み立て直す
通知を記録・集計する	台帳はkintoneやスプレッドシートに残し、Slackには知らせだけを送る

Slackは流れる場所なので、問い合わせの対応状況や障害の記録を長く残す台帳には向きません。問い合わせの件数や対応の進み具合を追いたいなら、kintoneやスプレッドシートに記録を残し、Slackには「届いた」「担当が決まった」の知らせだけを送る形にします。業務システムとつなぐ方法はkintone・Salesforce・n8nの連携の記事で書いています。

よく詰まるところ

症状	原因	直し方
送り先にプライベートチャンネルが出てこない	作る人がそのチャンネルに入っていない	チャンネルに参加してから「Add New Webhook to Workspace」をやり直す
「Authorize」のあとURLが出ない	アプリのインストールに管理者の承認が要る設定	管理者に承認してもらう
`@デザイナーB` と書いても通知されない	名前の文字ではメンションにならない	`<@U0000000000>` の形でIDを書く
メールの送信元が途中で消えて表示される	`<` `>` を書き換えていない	`&` `<` `>` を書き換えてから送る
Block Kitで送ると通知に何も出ない	`text` を入れていない	`blocks` と一緒に `text` を入れる
Apps Scriptの `onEdit` から送れない	単純トリガーは認証が必要なサービス（`UrlFetchApp` など）を使えない	インストール型の「編集時」トリガーで動かす
ある日から急に送れない・`no_service`	URLが削除された・漏れて無効にされた	一覧を確かめ、新しいURLを作って入れ替える
担当が辞めたあと通知が止まった	トリガーやURLがその人に結びついていた	共同管理者を置き、一覧表で持ち主を管理して作り直す
監視サービスから送ると `no_text`	サービスが決めた形のJSONしか送れない	Slack用の連携を使うか、ワークフロービルダーのWebhookトリガーで受ける
まとめて送ると一部が落ちる・429	1秒1件の上限を超えた	送り元で間をあけるか、まとめて1通にする
Windowsのcurlで `invalid_payload`	シングルクォートが効かない	PowerShellで送るか、エスケープを直す

送り元から届かないときに curl で同じURLへ送ってエラー名が返ってきているターミナル

次にやること

Webhookで「知らせる」ができたら、次は知らせたあとの動きを決めます。通知に対してボタンで担当を決めたい、スレッドにまとめたいなら、Slack APIとbotの作り方：Slackアプリを作ってメッセージを送る・受け取るに進みます。受け取った値で担当に振り分けたり、リストに残したりしたいなら、Slackのワークフロービルダー：作り方と、日報・申請・問い合わせ受付の例が近道です。案件の管理表をkintoneに移したあとの通知や承認は、Slackとkintone・Salesforce・n8nの連携：業務システムの通知と承認をつなぐで書いています。GoogleカレンダーやGitHubのように、公式のSlack連携があるサービスはWebhookを自作せず、Slackのアプリ連携：Googleカレンダー・Googleドライブ・GitHubをつなぐの手順でつなぐほうが手間がかかりません。

あわせて読む

画面に出てくる言葉の意味はSlack用語集で引けます。