自動化の見張り
自動化が止まったときに気づけるようにしたい｜Makeは既定でメールが届き、n8nは知らせ先を自分で作ります【2026年9月4日確認】
この記事の結論
- Makeは既定でメールが届きます。エラーで完走できなかったときと、エラーが続いて無効化したときの2つです。
- Makeは連続で失敗するとスケジュールごと止めます。既定は3回で、webhookで受ける形は1回目で止まります。
- n8nは知らせ先のワークフローを自分で1本作ります。手動実行では試せないので、わざと失敗させて確かめます。
料金・機能は2026年9月4日時点で公式サイトを確認した内容です
自動化は、うまく動いている間は何も言ってきません。止まったときも同じで、気づかないまま何日か過ぎることがあります。
Makeとn8nの公式ドキュメントを開いて、止まったあとに何が起きるのかを読み比べました（2026年9月4日確認）。
分かれたのは2つです。エラーの知らせが既定で届くかどうかと、失敗が続いたときにサービス側がスケジュールを止めるかどうかです。
なお、この記事にはMakeの紹介リンクがあります。n8nは申請が通っていないので、リンクを張れる相手ではありません。
Makeは、エラーで止まると既定でメールを送ります
止まったあとに何が起きるか
Makeのメール設定のヘルプは、既定で届くケースを2つ挙げています。原文は「By default, you receive emails in the following cases」で、その下に2行が並びます。
1行目はエラーでシナリオが完走できなかったとき、2行目はMakeがエラーを理由にシナリオを無効化したときです。
通知は3種類に分かれ、組織ごとに切り替えます
| 通知の種類 | ヘルプの説明 |
|---|---|
| Deactivation | エラーが原因でMakeがシナリオを無効化したことを知らせる |
| Warning | 対応が要る問題を知らせる。接続まわりの不調などが例に挙がっている |
| Errors | シナリオが完走できない原因になった問題を知らせる |
設定の場所はプロフィールページのEmail preferencesタブです。所属する組織ごとに、受け取る通知を変えられます。
届き方は、即時の1通とまとめの1通です
エラーか警告が起きた時点で、Makeはまず1通を送ります。そのあとMakeは続く警告やエラーを見張り、まとめの1通を送ります。
まとめが来るまでの時間も書かれています。エラーは5分後、警告は15分後です。
このまとめのメールにはシナリオの履歴へのリンクが入る、とヘルプは書いています。
続けて失敗すると、Makeはスケジュールごと止めます
Makeのエラー処理の概要ページは、連続エラーの既定値を書いています。原文は「The default number of consecutive errors is 3.」です。
3回続けてエラーで終わると、Makeはそのシナリオを無効化します。回数を変えるには、シナリオ設定の詳細設定の切り替えを開きます。
止める理由もエラーの入門ページに書かれています。失敗の繰り返しを防ぎ、調べて直すまでの時間を作り、operationの無駄な消費を避けるためです。
設定の名前が、2つのページで違います
概要ページはこの設定をNumber of consecutive errorsと呼んでいます。シナリオ設定のページは、同じものをErrors before deactivationと書いています。
画面で探すときは、両方の名前を頭に入れておくと早く見つかります。
webhookで動くシナリオは、1回目のエラーで止まります
シナリオ設定のページは、instant trigger（webhook）で始まるシナリオではこの設定を無視すると書いています。原文は「the setting is ignored and the scenario is deactivated immediately once the first error has occurred」です。
概要ページにも同じ例外が並んでいます。webhookで受けるシナリオには、3回の猶予がありません。
3種類のエラーが起きると、回数を待たずに止まります
| エラーの名前 | 概要ページの扱い |
|---|---|
| AccountValidationError | 起きた時点でMakeがスケジュールを無効化する |
| OperationsLimitExceededError | 同じく、その場で無効化する |
| DataSizeLimitExceededError | 同じく、その場で無効化する |
このほか、未完了の実行の保存が満杯でデータ損失の設定がオフのときも、Makeはシナリオを無効化すると概要ページに書かれています。
警告で終わったシナリオは、止まりません
Makeが止めるまでに、何回失敗できるか
概要ページは、警告を連続エラーの回数に数えないと書いています。警告で終わったシナリオは、そのあとも予定どおりMakeが動かします。
入門ページは、警告で終わる原因としてよくあるものを3つ挙げています。
| 入門ページが挙げる原因 |
|---|
| 未完了の実行を保存する設定を入れているときに、モジュールがエラーを出した |
| シナリオで使っているデータストアが容量の上限に達した |
| 1回の実行時間が、契約している上限を超えた |
エラーハンドラも警告の経路になります。RetryとCommitは警告で終わる、と概要ページが書いています。
どの経路でも、無効化までの回数は進みません。止まりにくくなる代わりに、無効化という強い知らせも来にくくなります。
Makeの無料プランを公式サイトで見る（通知の設定はプロフィールページ、止まるまでの回数はシナリオ設定にあります。2026年9月4日確認）
n8nは、知らせ先のワークフローを自分で1本作ります
n8nのワークフロー設定に、「Error Workflow (to notify when this one errors)」という項目があります。このワークフローがエラーになったときに知らせる先、という名前です。
知らせる先は、ワークフローとして自分で用意します。公式の手順は2段です。
手順は、作ってから選ぶの2段です
| 段 | 公式ドキュメントの手順 |
|---|---|
| 1 | Error Triggerを最初のノードに置いたワークフローを作って保存する |
| 2 | 知らせたい側のワークフローのSettingsで、そのワークフローを選ぶ |
公式は用途を「send email or Slack alerts when a workflow execution errors」と書いています。メールもSlackも、そのワークフローの中に自分でノードとして置きます。
同じ知らせ先を複数のワークフローで使い回せる、とも書かれています。Error Triggerを含むワークフローは、既定で自分自身を知らせ先にします。
手動実行では、その知らせを試せません
Error Triggerのページの原文は「You can’t test error workflows when running workflows manually.」です。
Error Triggerが動くのは、自動実行が失敗したときだけです。組んだその日に、エディタから手で回して知らせを確かめることはできません。
知らせに入る情報は、止まった場所で変わります
エラーがトリガーノードで起きた場合、ワークフロー自体が実行されません。そのため実行のIDと実行のURLが知らせに入らない、とエラー処理のページが書いています。
代わりに、エラーが起きたノードの情報が知らせに入ります。実行の記録を開いて追う手が使えないので、知らせの本文だけで原因を読むことになります。
設定しなくても、失敗の件数と失敗率は画面に出ます
知らせ先を作っていなくても、n8nは失敗の数を自分で数えています。Insightsのページは、直近7日の指標をOverviewの上部に出すバナーを説明しています。
バナーが出す指標に、本番実行の失敗件数と失敗率が入っています。同じページは、このバナーがCloudの全プランとセルフホストの全エディションで使えると書いています。
ただし、これは自分で開いたときに見えるものです。向こうから知らせが来る形ではありません。
私が読んだn8nの7ページに、自動で止める記述はありませんでした
Makeのように、続けて失敗したものをn8nの側で自動的に止める仕組みは、読んだ範囲では出てきませんでした。読んだページは記事の末尾に並べています。
n8n公式が失敗の調べ方として挙げているのは、実行の一覧を見ることとログの外部送信を有効にすることの2つです。
知らせ先の実行は、料金の枠には数えず、Insightsには数えます
n8nの実行の数え方のページは、枠に数えないものの一覧にエラーワークフローの実行を入れています。実行数そのものの数え方は作業を自動化したい記事で比べています。
一方でn8nのInsightsのページは、本番実行からデータを集めると書いたうえで「This includes error workflow executions.」と添えています。
エラー用ワークフローの実行は、失敗率などの指標には数えます。同じページは、失敗したエラーワークフローの結果をエラーワークフロー自身の記録として扱うとも書いています。
途中から再開できるかは、両社とも設定の項目です
止まった実行を最初からやり直すか、止まったところから続けるかは、Makeもn8nも設定で決まります。ただし既定をどちらにしているかを書いていたのは、Makeだけでした。
MakeのStore incomplete executionsは、既定でオフです
Makeのヘルプは「Incomplete executions are disabled by default.」と明記しています。オンにすると、エラーで止まった実行がIncomplete executionsタブに残ります。
オフのままだと、既定の処理はRollbackです。実行は巻き戻され、途中から続ける形は残りません。
この設定をオンにすると、3回での無効化と既定のメールが効かなくなります
概要ページは、この設定について「In addition, all scenario errors turn into warnings.」と書いています。エラーがすべて警告に変わります。
そして警告は、連続エラーの回数に数えません。3回で無効化される仕組みが、この設定を入れた時点で働かなくなります。
既定で届くメールの2件も、エラーと無効化の2つでした。警告はその2件に入っていません。
| 設定 | 途中から再開 | 3回での無効化 | 既定で届くメール |
|---|---|---|---|
| オフ（既定） | できない | 働く | エラーと無効化の2件 |
| オン | できる | 警告に変わるため進まない | 警告は既定の2件に入らない |
再開できるようにするか、止まったことを知らせてもらうか。この設定では、その2つを同時には取れません。
オンにしても、最初のモジュールで落ちたぶんは残りません
Makeの概要ページは、未完了の実行を保存しない条件を挙げています。ひとつが、シナリオの最初のモジュールでエラーが起きたときです。
同じページは回避策も書いています。最初のモジュールにRetryのエラーハンドラを付けると、この場合でも保存されます。
保存できる量は、契約している枠に紐づきます
保存した未完了の実行は、契約プランの保存容量に数えると公式が書いています。組織内の全チーム・全シナリオの合計に上限があります。
上限を超えたときの動きは、データ損失の設定で分かれます。オフならMakeがシナリオを止め、オンなら保存できなかったぶんを捨てて動き続けます。
n8nのSave execution progressも、同じ働きをします
n8nのワークフロー設定にSave execution progressという項目があります。公式の説明は「If set to Save, the workflow resumes from where it stopped in case of an error.」です。
同じ項目には、遅くなることがあるという但し書きも付いています。既定でどちらになっているかは、このページに書かれていません。
止まった実行のやり直しは、どちらも用意されています
n8nの実行一覧のページは、失敗した実行を選んで再実行する手順を書いています。選べるのは2つで、現在保存されているワークフローで回すか、当時のワークフローで回すかです。
Makeも、保存した未完了の実行を1件ずつ直すか、複数をまとめてやり直せると書いています。
ただし失敗した実行を保存するかどうかも、ワークフロー設定の項目です。Save failed production executionsという名前で並んでいます。
用途別の選び方
| やりたいこと | 合うほう | 理由 |
|---|---|---|
| 設定なしで、止まったことを知りたい | Make | メールで向こうから届くのはMakeだけ。n8nは自分で開けばバナーに失敗率が出る |
| 失敗が続いたら自動で止めてほしい | Make | 既定の3回でスケジュールを無効化する |
| 同じ知らせ先を、複数の自動化で使い回したい | n8n | 1本のエラー用ワークフローを複数から指定できる。Makeもエラー処理の経路にSlackのモジュールだけを置いて知らせられる |
| webhookで受ける形を、失敗しても続けたい | n8n | Makeはinstant triggerだと1回目のエラーで止まる。n8n側は、私が読んだ7ページに自動で止める記述がなかった |
| 止まったところから続けたい | どちらも設定が要る | MakeはStore incomplete executions、n8nはSave execution progress。Makeは既定でオフと明記 |
n8nはエラー用ワークフローの実行を枠に数えず、Makeはエラーハンドラが起動したぶんのoperationを消費しません。増えるのは組む手間のほうです。
よくある質問
無料プランでも通知は届きますか
私が読んだMakeの5ページに、通知をプラン別に分ける記載はありませんでした。連続エラーの設定についても同じで、プランごとの違いは書かれていません。
未完了の実行の保存容量だけは、契約プランに紐づくと明記されています。契約前に製品内で確かめるのが確実です。
通知が多すぎるときは止められますか
Makeはプロフィールページのメール設定タブで、組織ごとに種類を選べます。Deactivation・Warning・Errorsの3種類が対象です。
n8nは知らせ先が自分のワークフローなので、送るかどうかもそのワークフローの中で決めます。
止まったのに気づきにくいのは、どんなときですか
Makeでは、警告で終わったときです。警告はスケジュールを止めず、連続エラーの回数にも数えないので、シナリオは動き続けます。
n8nでは、知らせ先を設定していないときです。失敗の件数と失敗率はOverviewのバナーに出ますが、どちらも自分で開いたときに見えるものです。
エラーハンドラを置くと、止まらなくなりますか
Makeの概要ページによると、エラーハンドラは種類によってシナリオを止めるものと止めないものに分かれます。SkipとResumeは止めずに成功で終わり、Retryは止めずに警告で終わります。
n8nのノード単位のエラー処理は、私が読んだ7ページの範囲の外です。この記事では比べていません。
CommitとRollbackは止めます。未完了の実行をオフのままにしているときの既定がRollbackで、こちらだけがエラーとして終わります。
自動化を組んだ日に、通知の動作確認はできますか
n8nは、手動実行ではエラーワークフローを試せないと公式が明記しています。ただし待つ必要はありません。
エラー処理のページは、Stop And Errorノードを置くと決めた条件で実行をわざと失敗させ、エラーワークフローを動かせると書いています。公開して自動実行させたうえで、この形で1回失敗させれば知らせを確かめられます。
Make側については、通知の試し方の記載を読んだ範囲では見つけられませんでした。
実測してから追記します
同じ流れをMakeとn8nの両方で失敗させて、最初の1通が届くまでの時間と、3回目で本当に止まるかを数えて追記します。n8nの知らせが自動実行の失敗で発火するかも、そのときに確かめます。
この記事の数字の出所
Make
2026年9月4日に、次の5ページからHTML原文を取得しました。
同じ日にエラー処理の入口ページとエラーハンドラの一覧も取得しましたが、どちらも中身が下の階層への案内で、後者の2文もエラー処理の概要ページと同じ文でした。数える対象には入れていません。
既定で届く2つのケース、通知の3種類、即時の1通とまとめの1通、まとめまでの5分と15分は、メール設定のヘルプが書いています。
連続エラーの既定値3、webhookでの即時無効化、3種類のエラーの即時無効化、警告を回数に数えないことは、エラー処理の概要ページの記載です。
同じページから、エラーハンドラの5種類とその結果、エラーハンドラがoperationを消費しないこと、未完了の実行をオンにするとエラーがすべて警告に変わることも取りました。
無効化がシナリオを守るためであることと、警告で終わる原因3つは、エラーと警告の入門ページから取りました。
設定名Errors before deactivationと、未完了の実行の保存が容量に数えられることは、シナリオ設定のヘルプにあります。未完了の実行が既定でオフであることは、未完了の実行のヘルプの記載です。
n8n
同じ日に、次の7ページを公式ドキュメントのMarkdown版から取得しました。
設定の項目名、Error Triggerを使う2段の手順、手動実行では試せないこと、トリガーノードで止まったときに情報が減ることは、最初の3ページの記載です。
エラーワークフローの実行を枠に数えないことは実行の数え方のページ、Insightsには入ることはInsightsのページの記載です。失敗した実行の再実行の2つの選び方は、実行の一覧のページの記載です。
各ツールの詳細はMakeの記事・n8nの記事にあります。止まったときに読む場所の比較はブラウザの手作業をなくしたい記事にあります。
改定を見つけたときは、本文と結論と確認日を同時に更新します。
