Monitor Make.com scenarios with Hellhound

What Hellhound monitors in Make.com

Hellhound tracks each scenario run and detects:

What Hellhound cannot detect

Hellhound monitors at the scenario level, not the module level. It cannot see which specific module inside your scenario failed. For that, use Make.com's built-in error handlers alongside Hellhound.

What you need

Your API key authenticates Hellhound's webhook requests. You can find it in two places.

Option A — From the CLI

If you have the Hellhound CLI installed:

Copy the api_key value. You will use it in the next steps.

Option B — From the dashboard

Your API key was shown once when you registered on hellhound.dev. If you did not save it:

1. Log in at hellhound.dev/dashboard
2. Go to Account Settings → API Key
3. Click "Generate new key" and confirm with your password
4. Copy the new key — it is shown once

Add an HTTP Request module as the FIRST module in your scenario, immediately after your trigger.

How to add it in Make.com

1. Open your scenario in Make.com
2. Click the + button after your trigger
3. Search for "HTTP" and select HTTP → Make a request
4. Configure the module with these exact settings:

Important — naming your scenario:

The automation_name is how you identify this scenario in your Hellhound dashboard and in alert messages.

Use the same name consistently in both run-start and run-end.

Save the run ID

The run-start response returns a run_id. You need to pass this to the run-end module so Hellhound can match them.

After adding the HTTP module, configure the response parsing:

5. Under Response → Parse response: Yes
6. Under Response → Output type: JSON

Make.com will now expose the run_id in the data bundle. You can reference it as:

Response shape:

Add an HTTP Request module as the LAST module in your scenario, after all your other modules complete successfully.

Settings

Replace {{1.run_id}} with the actual reference to the run_id from your run-start module. The module number depends on where you placed run-start in your scenario.

This step is critical. Without error handling, Hellhound only detects hung scenarios (where run-end never arrives). With error handling, it catches explicit failures too.

How to add error handling in Make.com

Make.com has two ways to handle errors:

Method 1 — Error handler route (recommended):

1. Right-click any module in your scenario
2. Select "Add error handler"
3. Choose "Break" route type
4. Add an HTTP Request module to the error route

Method 2 — Scenario error settings:

Use Make.com's built-in error notification alongside Hellhound's error webhook for maximum coverage.

Settings for the error handler HTTP module:

Note: {{error.message}} is Make.com's built-in variable that contains the error from the failed module.

What this looks like in your scenario

Result in Hellhound:

When a module in your scenario fails, Hellhound immediately receives:

•   success: false
•   error_message: "the actual error from Make.com"

You get an alert within seconds of the failure, not hours later when you happen to check Make.com's execution history.

Tell Hellhound where to send alerts for this scenario.

Install the CLI first if you haven't:

Then add your alert destinations:

Run your scenario once manually in Make.com to verify Hellhound is receiving the signals correctly.

How to test

1. Open your scenario in Make.com
2. Click "Run once" at the bottom
3. Watch the execution — all modules should turn green
4. Open your Hellhound dashboard

You should see:

• ✓ Your scenario name appears in the agent list
• ✓ Run #1 shows in the run history
• ✓ Status: ok
• ✓ Duration recorded

Verify via CLI

Expected output:

Test error detection

To verify error handling works, temporarily add a module that fails intentionally:

1. Add a Tools → Error (throw error) module before your run-end
2. Run the scenario once
3. You should receive an alert immediately
4. Check your dashboard — the run should show as "failed"
5. Remove the error module when done

Naming your scenarios

Good automation names make your dashboard readable when you are monitoring 20+ scenarios for multiple clients.

Good naming patterns:

Format: {client}-{what-it-does}

Why this matters:

When you get a 3am Slack alert saying:

You know immediately:

• — Which client is affected (Acme)
• — Which automation is broken (lead enrichment)
• — Which person to potentially notify

Compare to getting an alert saying:

At 3am you have no idea what that is.

Keep names consistent:

The automation_name in your HTTP modules must match exactly what you use in hellhound alert add --name.

If you rename a scenario in Make.com, update the automation_name in your HTTP modules to match.

Monitoring multiple scenarios

Each Make.com scenario gets its own automation_name. There is no limit on how many scenarios you can monitor.

Setting up multiple scenarios

Repeat steps 2-5 for each scenario. The only thing that changes between scenarios is the automation_name in the request body.

Everything else — API key, URL, method, headers — stays identical across all your scenarios.

Reusing a Make.com HTTP module template

Save time by creating the HTTP Request modules once and copying them between scenarios:

1. Right-click the HTTP Request module in Make.com
2. Select "Copy"
3. Open another scenario
4. Paste the module
5. Update only the automation_name in the request body

The URL, method, and headers stay the same.

Setting alerts for each scenario

Each scenario can have different alert destinations. This is especially useful if different scenarios belong to different clients — you can alert the right person for each one.

Plan limits

If you hit the Pro limit, upgrade to Agency at hellhound.dev/pricing.

A complete working example

Here is a minimal Make.com scenario with Hellhound monitoring configured correctly.

Scenario: Lead enrichment — runs every 15 minutes, fetches new leads from a form, enriches via an API, saves to a CRM.

Key points from this example:

Common issues and fixes

Make.com questions