n8n¶
The verified community node n8n-nodes-lumatrack records one run event per
workflow execution. Drop it at the end of a workflow and the value report
builds itself.
Install¶
n8n-nodes-lumatrack is a verified community node, so it is available
on n8n Cloud as well as self-hosted: search for "LumaTrack" in the nodes
panel and install it from there, or go to Settings, Community Nodes,
Install and enter n8n-nodes-lumatrack
(npm listing).
Every n8n workflow can also always report through plain HTTP
with an HTTP Request node.
Credentials¶
Create a "LumaTrack API" credential:
| Field | Value |
|---|---|
| Base URL | Your LumaTrack host, e.g. https://lumatrack.example.com |
| API key | From Settings, API keys in LumaTrack (shown once at creation) |
An ingest-only key is enough for Record Run and Record Incident, and is the one to use in workflows: if it leaks, an attacker can post junk runs but cannot read or restate your ledger. Resolve Incident and Get ROI Summary change or read existing evidence, so those two need a full-access key.
Operations¶
Record Run (the default) reports one execution to the value ledger. Record Incident reports one loss event to the loss ledger and Resolve Incident stamps it resolved with measured downtime. Get ROI Summary returns the organization's realized value summary, so a workflow can route on value. The node is also usable as an AI Agent tool.
Record Run fields¶
| Field | Notes |
|---|---|
| Automation | A dropdown of your automations (or a slug by expression); create them in the app or API |
| Status | Success, Failure, Skipped or Cancelled |
| Failure reason | Shown for failures; the root cause, e.g. auth/credential or your error branch's message. Powers the failure-reason Pareto |
| Units from input items | Report ONE run for the whole execution with units = the input item count; the recommended pattern after a loop |
| Units processed | Records/items the execution worked through, e.g. ={{ $json.items.length }}. -1 omits the field (server default: 1). Drives per-unit valuation |
| External ID | Defaults to the n8n execution id, which makes retries idempotent automatically |
| Executed at | ISO 8601, for evidence that genuinely happened earlier (reporter workflows); empty means now |
| Duration (seconds) | -1 omits the field; 0 is a real zero-second run |
| Baseline minutes override | The total manual minutes this one execution replaced, overriding the automation's standard baseline for this run only. -1 omits the field; 0 is a real assertion. Map it from a source system that genuinely knows the manual size of the occurrence, e.g. ={{ $json.category_handle_minutes }} from your ticket platform. See Asserting a baseline per run |
| AI usage | Model + token counts from your AI Agent node; LumaTrack prices them server-side (AI workloads), with metered or flat-rate-subscription billing |
| Metered usage | Actual per-unit cost-component consumption, by component name, e.g. {"tokens": 1840} |
| Metadata | Arbitrary JSON kept with the run; invalid JSON fails the node with a clear message |
The node honors n8n's Continue On Fail setting: with it enabled, a
LumaTrack outage records an error item instead of failing your workflow.
If a response carries a non-empty ignored_fields list, a field in your
payload was misspelled; treat it as a bug, never a silent success.
Record Incident fields¶
| Field | Notes |
|---|---|
| Event type | A dropdown of your loss event types (or a slug by expression); create them under Incidents in the app |
| Downtime (minutes) | MEASURED downtime only; -1 omits the field (0 is a real zero) |
| Cost override | The actual total cost as a decimal, e.g. 412.50; empty lets LumaTrack compute it from the event type's cost model |
| External ID | Must be unique per incident; the default combines the execution ID and item index so a batch of N alerts books N incidents, while retried deliveries never double-count. Use your ticket or alert ID when one exists |
| Occurred at | ISO 8601 for incidents that genuinely happened earlier; empty means now, frozen months are refused |
| Metadata | Arbitrary JSON kept with the incident |
A watcher workflow on your ticket queue or RMM alerts plus one Record
Incident node turns raw alerts into dollarized, auditable incident records.
Resolve Incident takes the incident's evt_... ID (from a Record
Incident output or an Incident Recorded trigger event) and optional total
measured downtime.
The trigger node¶
LumaTrack Trigger starts a workflow when LumaTrack sends a webhook
event (a run held over the plan cap, a period closing, an incident
recorded or resolved, an initiative implemented, and more; the full
catalog is in webhooks). Set it
up in two steps: activate the trigger and copy its webhook URL into
LumaTrack under Settings, Webhooks (format JSON), then paste that
endpoint's signing secret into the node. Every delivery is verified
against its X-LumaTrack-Signature (HMAC-SHA256 of the exact body);
unsigned or mis-signed posts are rejected. An event filter on the node
narrows which events start the workflow.
While building, paste the trigger's TEST webhook URL into the LumaTrack endpoint's optional Test URL field: Send-test deliveries then reach the editor's listen mode, signed with the same secret as production, so you can execute downstream nodes without ever swapping secrets.
Wire the error path too¶
One LumaTrack node at the end of the success path with Status = Success is half the integration. The other half: attach an error workflow (or an error branch) with a LumaTrack node set to Status = Failure. Failed executions cost money and save nothing; reporting them is what makes the reliability chart and the net numbers credible.
Many workflows, one automation?¶
Map them however your accounting works. If three workflows together replace one manual task, point all three at the same automation slug. If one workflow does two unrelated jobs, consider splitting it, or pick the slug per branch with an expression.
Sub-workflows and loops¶
Sub-workflows just work. n8n's own time-saved metric only credits top-level executions; LumaTrack does not inherit that limitation because the node reports from wherever it sits. A LumaTrack node inside a sub-workflow reports that sub-workflow's own execution (sub-executions get their own n8n execution IDs, which is the node's External ID default, so idempotency holds). Give the sub-workflow its own automation slug with its own baseline and it is a first-class automation; no webhook workarounds, no environment-specific URLs (the target host lives in the credential, not in workflow JSON).
A node inside a loop needs care. All iterations of one execution share the same execution ID, so the External ID default dedupes every iteration after the first into a single run; a per-item time-saved multiplier silently becomes 1x. Two fixes, in order of preference:
- Aggregate, then report once with units (recommended). Put the
LumaTrack node after the loop and set Units processed to the item
count, e.g.
={{ $items().length }}on the aggregated input. One run, honest volume, and per-unit valuation prices the batch as fixed setup + marginal minutes per record, the number that survives review. - Unique external IDs per item, e.g.
={{ $execution.id }}-{{ $itemIndex }}, when each item genuinely is its own run (its own success/failure, its own duration). Note each item then consumes one event against your plan's monthly cap.