Operating automations

T05-L05 · Automation · Level 5 Operator · 45 minutes

At this level, an automation is a service rather than a canvas. Forty workflows can fail, slow down, accumulate work, or spend money while their individual executions still look plausible. Operation means detecting that change, finding the affected run, limiting impact, and recovering without depending on the builder's memory.

2. Nine quiet days

Forty workflows are running. The weekly digest built in T05-L03 and made safe to fail in T05-L04 has a durable job ID, bounded retries, a dead-letter queue, approval, and an idempotent mock effect. That makes one execution safer. It does not tell an operator that no successful digest has arrived for nine days.

In the Lab, the literature pipeline began rejecting every PubMed response after a source-field change. Each run stopped safely, so no unsupported review was produced. In the Company, the equivalent inbox pipeline continued to complete, but an oversized-message branch made model calls repeatedly and its spend exceeded all other workflows combined. Nobody had a workflow-level dashboard, a useful threshold, or a written on-call expectation. The monthly invoice revealed the Company problem; a group meeting revealed the Lab problem.

Safe failure is necessary but not sufficient. You must monitor runs and alert on failure rate, trace a bad output back to its run, and track cost per workflow with an enforced hard cap. Every workflow needs a runbook that says what alerts, who responds, how to stop it, and how to replay safely. If the original builder leaves, another authorised operator must still be able to do those things.

3. After this you can

• Monitor success, failure rate, duration, queue depth, and spend by stable workflow and revision identifiers.
• Alert on actionable thresholds, including missing expected runs, without training responders to ignore noise.
• Trace one output through its run, safe input reference, branches, model observations, approval, and effect record.
• Attribute observed usage and cost to a workflow and enforce a pre-call budget reservation that stops runaway spend.
• Write and rehearse one runbook with named response, stop, investigation, and safe-replay procedures.

4. Prerequisites

• T05-L04 · Making an automation safe to fail, including durable job claims, bounded retries, watched dead letters, approvals, an effect key, and a circuit breaker.
• T12-L05 · Governance, evidence and handover, including a named system owner, risk tier, data boundary, retention decision, and substitute operator.
• The disabled synthetic Lab or Company workflow from T05-L04, its disposable PostgreSQL control tables, and permission to add disposable operations tables.
• An approved n8n test project, a Langfuse test project or equivalent trace store, and an approved alert destination. Uptime Kuma or an equivalent availability monitor is optional for heartbeat checks.
• A named primary responder, substitute responder, budget owner, privacy or retention owner, and reviewer with access to the controls they are expected to use.
• About 90 minutes for the independent operating drill.

Use only the synthetic records in this book, public bibliographic metadata, or explicitly approved data. Keep the workflow non-production and its destination mocked. Do not copy inbox messages, unpublished manuscripts, participant or patient data, employee details, customer records, credentials, prompts, full model responses, or author addresses into alerts, dashboards, runbooks, or traces. Store secrets only in approved credential or secret stores. A test alert must reach an authorised internal test channel and must not page a real production rotation.

5. The idea in one page

Operation joins four kinds of evidence around one stable identity:

safe input reference -- job key --> workflow run -- trace ID --> observations
                                      |     |             |
                                      |     |             +-> usage and cost
                                      |     +-> branch, duration, terminal state
                                      +-> output reference -> approval -> effect key

aggregated run events -> health dashboard -> actionable alert -> named responder
usage reservation ----> hard cap ------^              |
heartbeat ------------> no-run alert -----------------+
                                                       v
                                        runbook: stop, inspect, replay, close

Metrics answer aggregate questions. Count started, succeeded, failed, dead-lettered, and still-running executions over a window. Measure duration from start to terminal state. Measure queue depth as work waiting now, preferably with age of oldest item. Sum observed cost and outstanding reservations by workflow. Keep dimensions bounded: workflow key, revision, environment, terminal class, and profile are useful; raw input, arbitrary error text, execution ID, and user text are not metric labels.

Use a denominator. “Five failures” means something different for six runs and six thousand. A failure rate for a completed-run window is:

terminal failures / (terminal successes + terminal failures)

Report volume beside the rate and classify cancelled test runs consistently. Queue depth and duration need distributions, not only averages: one stuck job can disappear inside a healthy average. Also monitor absence. A weekly pipeline that has emitted neither success nor failure is not healthy merely because its failure rate is zero.

Alerts are requests for a person to act. Every alert needs a condition, evaluation window, severity, destination, primary responder, response objective, first action, recovery condition, and test date. Start from measured normal behaviour and service consequence. Use a minimum run count before a percentage alert, combine sustained rate with a severe single-event route, and notify on state transitions rather than every failed execution. Alert separately when expected data is absent. Review noisy alerts; do not solve fatigue by muting them indefinitely.

Tracing answers one-run questions. Carry one generated run_ref from trigger to every branch and one stable workflow_key across revisions. Preserve source_job_id, workflow_revision, safe_input_ref, branch decisions, model route, usage, validation result, approval reference, output reference, and effect key. Store only the content required by the approved retention policy. A trace ID without output linkage cannot explain a bad digest; a searchable raw digest without minimisation creates another data store.

Cost control has two loops. The accounting loop records provider-reported usage and cost, or a clearly labelled estimate, against the workflow and trace. The enforcement loop checks and atomically reserves remaining budget before an expensive call. A dashboard or monthly invoice is not a cap. Because final cost is known after a response, reserve a conservative maximum, then reconcile it to observed cost. Expired reservations need a controlled sweeper. Never allow a failed telemetry write to make the model call free.

A runbook connects detection to action. It is not an architecture essay. It gives an authorised responder exact, tested steps to acknowledge, stop new work, preserve evidence, assess impact, restore a dependency, replay only eligible work, verify recovery, and communicate. On-call is a written expectation: coverage hours, destination, response objective, escalation, authority to stop, and handoff. “Ask Maya” is not a procedure.

6. The worked example: operate the weekly digest

Instrument the same Weekly digest service from T05-L03 and the safe preparation pattern from T05-L04. The Lab profile queries approved public PubMed metadata and produces an internal literature-review candidate. The Company profile processes only the fictional inbox fixtures from the earlier book and produces an internal triage candidate. Both use the same control plane. Neither sends a message or changes a live system.

Name the service and its operating boundary

Do not use a mutable display name as the only key. Record this in the workflow description and governance inventory:

workflow_key: weekly-digest-v1
environment: training-test
workflow_revision: [export or source-control revision]
profiles: lab | company
expected_schedule: one approved weekly run per selected profile
allowed_output: internal review candidate only
irreversible_effect: none in this exercise
stop_authority: primary or substitute automation operator
data_boundary: synthetic fixtures or approved public bibliographic metadata
retention: [approved periods for metrics, trace metadata, and execution data]

The schedule expectation belongs outside the workflow as well as inside it. If the scheduler, n8n instance, or complete workflow stops, an internal Error Trigger cannot report the silence. Configure an independently operated heartbeat or scheduled check. Uptime Kuma may check an approved internal health endpoint or a heartbeat mechanism, but an HTTP 200 from n8n proves only reachability. The operational success signal is a recently completed synthetic canary or expected run with the correct terminal state.

Emit one bounded run event contract

Add a start event before source access and one terminal event on every explicit branch. The Error Trigger normalises unexpected failures into the same contract. Extend the disposable database with an operations table, or send equivalent structured events to the approved monitoring system:

create table automation_run_events (
  run_ref text not null,
  workflow_key text not null,
  workflow_revision text not null,
  environment text not null,
  profile text not null check (profile in ('lab', 'company')),
  event_type text not null check (event_type in ('started', 'terminal')),
  terminal_class text check (terminal_class in (
    'success', 'no_results', 'needs_scope', 'input_review',
    'dead_letter', 'reconcile', 'circuit_open', 'budget_blocked',
    'unexpected_failure', 'cancelled_test'
  )),
  safe_input_ref text,
  source_job_id text,
  trace_id text,
  output_ref text,
  error_ref text,
  queue_name text,
  observed_cost numeric(12,6),
  occurred_at timestamptz not null default now(),
  primary key (run_ref, event_type),
  check (
    (event_type = 'started' and terminal_class is null) or
    (event_type = 'terminal' and terminal_class is not null)
  )
);

One primary key makes duplicate event delivery harmless. Restrict the workflow credential to approved inserts or reviewed stored procedures; do not grant schema-owner access. observed_cost is nullable until cost is known and must carry currency and rate-source metadata in the cost ledger described below. Do not put raw exception strings into low-cardinality metrics.

Make the catch-all reproducible rather than inventing a class from each exception. The n8n Error Trigger, or an equivalent outer error handler, must marshal every unhandled node error, timeout, process loss reported by the platform, and unmapped exception to terminal_class = 'unexpected_failure'. It recovers the already-created run_ref from execution metadata, emits one terminal event, puts only an opaque restricted-log pointer in error_ref, and never copies the exception message into a metric label or alert. An authorised drill cancellation is cancelled_test; an unplanned cancellation is unexpected_failure. If the handler cannot write its event, the independent stale-run check must alert on the unmatched start. Test both the mapping and that fallback.

At trigger time, generate or receive run_ref once. Do not overwrite it in sub-workflows. Pass it as trace metadata and through the candidate-output row. Add output_ref to the internal digest artifact, for example DIGEST-SYN-2026-W36-LAB, while keeping run_ref available to authorised operators rather than displaying internal diagnostics to general readers.

The dashboard for each profile shows:

Define the numerator and denominator from named sets, not from whatever labels happened to arrive. For this example, reliability successes are success and no_results; reliability failures are dead_letter, reconcile, circuit_open, budget_blocked, and unexpected_failure. The failure rate is the count in the failure set divided by the count in the success and failure sets. needs_scope, input_review, and cancelled_test are reported as deferred or drill outcomes and excluded from that rate. A separate count makes that exclusion visible. Repeated needs_scope still warrants an operational warning because the service is producing no digest. budget_blocked confirms that the cap worked, but it remains a failed service outcome requiring budget-owner review.

Set alerts people can act on

Run normal synthetic cases first and record baseline volume and duration. Then approve a small training policy:

The numbers are training values, not universal defaults. In a low-volume weekly service, the stale alert is more useful than a 15-minute failure percentage. In a busy Company inbox, a rate plus minimum count may be appropriate. Keep warning and paging severities distinct. Include only workflow key, environment, condition, window, dashboard or trace link, runbook link, and acknowledgement route in the notification. Do not include source text, prompt, response, email address, or secret.

Trigger one real delivered test alert by injecting five synthetic terminal events, one of which is success and four of which are dead_letter, inside the test environment and alert window. That creates an 80% observed failure rate. The named responder must receive and acknowledge the notification through the actual approved test route. Record alert ID, sent time, received time, acknowledgement time, calculated numerator and denominator, and links to the synthetic event IDs. Then remove the fixtures or let the isolated test window expire and confirm a recovery notification. A screenshot of alert configuration is not evidence of delivery.

Use Uptime Kuma only for the independently reachable health or heartbeat check it can actually perform. Use n8n execution data or exported metrics for workflow outcomes. Use Langfuse alerts or the approved metrics platform for model cost and quality dimensions it receives. Do not make three tools page three people for the same symptom: choose one alert owner and deduplicate downstream.

Trace a bad output to its cause

Create a fictional bad Lab output whose candidate says sample size 0 where its synthetic source says “not reported.” For Company, use a fictional triage candidate routed to billing-standard despite the fixture containing “cancel my account.” Give it one output_ref and start with only that reference, as a colleague reporting the issue would.

The investigation path is deterministic:

1. Find the output record by output_ref; recover run_ref, workflow revision, approval state, and effect key if any.
2. Find the run event by run_ref; confirm profile, source job, terminal class, duration, and safe input reference.
3. Open the corresponding Langfuse trace or equivalent by trace_id; verify the model route, prompt revision, context references, branch sequence, validation result, usage, and cost.
4. Resolve safe_input_ref in the authorised source store. Compare the retained synthetic fixture or public source reference with the model observation and parser output.
5. Decide where the fault first appeared: source adapter, branch, retrieval, model generation, parser, validation, approval, or effect.
6. Record impact and stop condition. Do not edit the historical trace or silently replace the output.

A useful restricted trace summary looks like this:

output_ref: DIGEST-SYN-2026-W36-LAB
run_ref: RUN-SYN-OPS-014
workflow_key/revision: weekly-digest-v1 / rev-17
safe_input_ref: fixture://lab/LAB-MISSING-02@sha256:[recorded hash]
trace_id: trace-syn-014
branches: accepted_batch -> extracted -> synthesis -> human_review
model_route: [approved exact test route]
validation: schema_pass; semantic boundary failed in review
usage/cost: [provider-reported units] / [reconciled synthetic or test cost]
approval/effect: rejected / none
first_bad_stage: generation

Langfuse tracing can associate nested observations, usage, latency, cost, and metadata, but its ability to store input and output does not make unrestricted retention appropriate. Prefer fixture references, hashes, categories, and redacted structured values where those are enough. Restrict readers and test deletion according to the governance record. Keep n8n execution-retention settings aligned: a runbook that links to already-pruned evidence cannot support its claimed investigation period.

Attribute cost and enforce the cap

Tag every model observation with workflow_key, workflow_revision, environment, profile, run_ref, and model route. Ingest provider-reported usage and cost when available. If a model definition infers cost, record the model-pricing revision and distinguish the estimate from invoiced cost. Validate the calculation against a small provider statement or gateway export on a schedule. Never sum overlapping usage buckets twice.

For a safe training cap, create a budget row and a call-reservation ledger in the disposable database using synthetic currency units. The production equivalent belongs at the gateway or another enforcement point that every costly route must cross:

create table automation_budget_periods (
  workflow_key text not null,
  period_start date not null,
  currency text not null,
  limit_amount numeric(12,6) not null check (limit_amount >= 0),
  primary key (workflow_key, period_start)
);

create table automation_budget_ledger (
  workflow_key text not null,
  period_start date not null,
  reservation_id text not null,
  call_ref text not null,
  run_ref text not null,
  state text not null check (state in ('reserved', 'reconciled', 'released')),
  reserved_amount numeric(12,6) not null check (reserved_amount > 0),
  observed_amount numeric(12,6) check (observed_amount >= 0),
  provider_request_id text,
  rate_source text not null,
  updated_at timestamptz not null default now(),
  primary key (workflow_key, period_start, reservation_id),
  unique (workflow_key, period_start, call_ref),
  foreign key (workflow_key, period_start)
    references automation_budget_periods (workflow_key, period_start),
  check (
    (state = 'reconciled' and observed_amount is not null) or
    (state in ('reserved', 'released') and observed_amount is null)
  )
);

run_ref groups all work in one workflow run. call_ref identifies exactly one potentially chargeable provider attempt, including a retry; reservation_id identifies the hold created for that attempt. Generate and persist both before enforcement. One run may therefore have many ledger rows. Never reuse a call_ref for a new attempt after an ambiguous response, and never use run_ref as the reservation key. Record the provider request ID during reconciliation when it is available.

Set an intentionally small test cap of 10 synthetic units and a conservative maximum of 3 units per call. Constrain request size and use an approved current rate so the reservation really upper-bounds that route; deny a call whose maximum cannot be bounded. Before every costly call, the mandatory wrapper performs one reviewed transaction:

1. Lock the matching row in automation_budget_periods with SELECT ... FOR UPDATE.
2. Look up call_ref. If it already exists, return its recorded state without creating another hold or issuing another provider request; reject any mismatch in reservation ID, run, route maximum, or rate source. A caller must reconcile an ambiguous existing attempt rather than replay it.
3. Sum reserved_amount for reserved rows and observed_amount for reconciled rows; contribute zero for released rows.
4. Insert the new reservation_id and call_ref only if that sum plus the requested maximum is no greater than limit_amount; otherwise roll back and emit budget_blocked.
5. Commit a genuinely new reservation. Only that new path may make the provider request, carrying call_ref as an idempotency key where the provider supports one.

The period-row lock serialises reservations for that workflow and period, while the unique call_ref makes a repeated wrapper request idempotent. A dashboard query followed by an insert can race; so can separate “check” and “reserve” API calls. A serializable transaction or gateway-native compare-and-reserve operation is also acceptable, but it must provide the same atomic invariant and fail closed when unavailable.

When the provider response arrives, reconcile that reservation_id to observed amount and attach the provider request ID. If the call provably never started, release that reservation. If the result is ambiguous, keep it reserved and route it for reconciliation. A scheduled sweeper may flag old reservations, but it must not release them merely because they are old. The budget owner first determines whether a charge could exist. A retry that could create another charge requires its own call and reservation identities.

Run four synthetic call attempts, each with distinct call and reservation identities, for 3 units. The first three reserve 9; the fourth must end at budget_blocked before a model request, leaving the total at 9. Re-submit one of the first three call_ref values and prove it returns the same hold rather than reserving again. Confirm that two simultaneous new calls near the boundary cannot exceed 10. Then reconcile the three reservations to their synthetic observed amounts and compare the ledger total with the trace-cost total. Preserve the difference as a metric. The cap test fails if the fourth model call occurs, if any costly route bypasses the wrapper, if a telemetry outage bypasses enforcement, or if changing a dashboard threshold is presented as a hard stop.

Write and rehearse the runbook

Create one runbook for weekly-digest-v1, not separate Lab and Company documents. Put profile-specific contacts or impact in fields within it. Use this minimum structure:

SERVICE: workflow key, purpose, environment, revision source, governance entry
DATA: allowed classes, prohibited fields, trace/execution retention, readers
DEPENDENCIES: scheduler, n8n, database/queue, source, model route, trace store, alert route
EXPECTED: schedule/volume, duration band, queue objective, budget period and cap
ALERTS: exact conditions, severity, destination, dashboard, test date
ON-CALL: coverage, primary, substitute, response objective, escalation, stop authority
STOP: exact project and workflow names; pause trigger then dispatcher; verify no new claims/effects
INVESTIGATE: output_ref -> run_ref -> trace_id -> safe_input_ref; preserve event IDs
REPLAY: eligibility, approval, source snapshot, replay lineage, dry run, effect safeguards
RECOVER: dependency check, one synthetic canary, threshold windows, queue reconciliation
COMMUNICATE: incident owner, affected period/output refs, safe internal channel
REVIEW: owner, last rehearsal, next review, changes since rehearsal

The stop procedure must fit the deployed topology. For the training workflow: disable the schedule or inbound trigger, disable the separate approved dispatcher, confirm no new job claims for two expected polling intervals, inspect running executions, and leave ambiguous effects in reconcile. Do not kill the database or delete queue rows to make a graph look quiet. Record who can perform each action and what to do if that person lacks permission.

Replay is not “click retry.” Only replay a job whose source is still authorised, whose failure occurred before any irreversible or ambiguous effect, and whose cause is corrected. Record replay_run_ref, original_run_ref, original source job ID, safe input snapshot or reference, approved workflow revision, reason, approver, and time. Re-enter before the failed reversible stage through a dedicated replay entry point. Keep the original stable effect key. First run in dry mode to internal review; then require the normal approval gate. Completed jobs are not replay candidates. reconcile jobs must be reconciled at the destination before any further effect. The durable claim and output linkage from T05-L04 remain controls rather than obstacles to work around.

Ask the substitute operator to use only the runbook to acknowledge the injected failure-rate alert, locate one synthetic failed run, disable both named workflows, explain why the fourth budget attempt was blocked, and dry-replay one eligible pre-effect dead letter. The primary operator observes but does not provide hidden steps. Restore only the approved test configuration and leave the workflow disabled after the drill.

7. What goes wrong

Every failure produces a page

Symptom: a temporary dependency incident sends forty nearly identical notifications, and later alerts are ignored.

Fix: aggregate over a window, add a minimum denominator, notify on state transitions, route severe single events separately, and test recovery. Preserve per-run events for investigation without paging per event.

A green health check hides a dead workflow

Symptom: the n8n login page returns 200, but the scheduled digest has not completed for nine days.

Fix: monitor both platform reachability and the freshness of an expected successful or explicit valid terminal event from outside the workflow.

The output has no run identity

Symptom: a colleague reports a wrong digest, but operators can search only by approximate time and text.

Fix: persist output_ref -> run_ref -> trace_id -> safe_input_ref and test that path from the output, not from a trace you already know.

Cost appears only on the invoice

Symptom: a workflow's spend is visible after the budget period, with no per-run or per-workflow attribution.

Fix: collect provider usage at each model observation, tag it with stable workflow identity, reconcile totals, alert before the cap, and enforce reservation before calls.

The cap is only a chart line

Symptom: simultaneous runs all start after seeing apparent headroom, crossing the displayed budget.

Fix: make reservation atomic at a mandatory enforcement point. Fail closed or enter a deliberately approved degraded mode when enforcement is unavailable; do not treat missing telemetry as zero cost.

Replay repeats the effect

Symptom: an operator retries a completed or ambiguous execution and creates a second message or update.

Fix: replay only eligible pre-effect failures through a dedicated entry point, preserve lineage and the original effect key, dry-run to review, and reconcile ambiguity before action.

The runbook names a person, not a procedure

Symptom: the alert says “ask the builder,” and the substitute cannot stop or investigate the service.

Fix: write exact controls, permissions, queries, evidence paths, and escalation. Rehearse with the substitute while the builder remains silent.

8. Do it yourself: operate one workflow in 90 minutes

Use the Lab literature profile or Company inbox profile with synthetic data and mock effects. Produce one runbook throughout; evidence from the drill is embedded in that artifact rather than delivered separately.

Minutes 0–10: record workflow key, revision, purpose, data boundary, owners, expected schedule, terminal classes, retention, and exact stop authority. Verify secrets and raw content are excluded from the runbook.

Minutes 10–25: emit start and terminal events with run_ref, add the output-to-run link, and build the five-signal dashboard: failure rate with volume, duration, queue depth and age, spend, and freshness.

Minutes 25–38: write alert windows, thresholds, minimum counts, no-data behaviour, recipients, first actions, and recovery. Inject bounded synthetic failure events and obtain a real delivered and acknowledged test alert.

Minutes 38–50: begin from one fictional bad output_ref. Trace it to run, safe input, branch, model observation, validation, approval, usage, and cost. Record the first bad stage without retaining prohibited content.

Minutes 50–63: apply the 10-unit synthetic cap and distinct 3-unit call reservations. Prove three calls can reserve, a duplicate call_ref cannot reserve twice, and a fourth new call is blocked before the provider request. Test two near-boundary reservations concurrently and reconcile trace and ledger totals.

Minutes 63–75: complete the runbook's exact stop, investigation, replay, recovery, communication, on-call, and escalation fields. State coverage honestly; if nobody is expected to respond overnight, the workflow must have a bounded overnight failure mode.

Minutes 75–86: have the substitute acknowledge the alert, stop trigger and dispatcher, inspect the bad output, and dry-replay one eligible pre-effect failure using only the runbook. Do not replay a completed or ambiguous effect.

Minutes 86–90: verify no new claims or mock effects occurred during stop, confirm alert recovery, remove synthetic alert fixtures, release only proven-unused reservations, remove temporary access, date the rehearsal, and leave the workflow disabled.

9. Exit check

Deliver exactly one artifact: one written runbook for one workflow covering what alerts, who responds, how to stop it, and how to replay it safely.

It passes when the runbook identifies the workflow and revision source; expected schedule; named reliability sets including unexpected_failure; duration, queue, freshness, and spend signals; alert conditions, recipients, response objectives, first actions, and recovery; primary and substitute responders; exact trigger and dispatcher stop controls; the output_ref -> run_ref -> trace_id -> safe_input_ref investigation path; cost attribution and the mandatory hard-cap enforcement point; replay eligibility, lineage, dry-run, approval, and effect-key safeguards; data boundary and retention; escalation and communication; and review date. Embedded drill evidence must show one synthetic threshold crossing produced an actually received and acknowledged alert, the stop prevented new claims or effects, one bad output was traced to its first bad stage, distinct call and reservation identities prevented a duplicate hold, the fourth new call was denied before a provider request, and a substitute completed one eligible dry replay using only the runbook.

It fails if alert configuration substitutes for receipt, monthly visibility substitutes for an enforced cap, raw or unapproved data enters evidence, replay can repeat an ambiguous or completed effect, or the procedure depends on undocumented knowledge from the original builder.

10. Rule to remember

If nobody is alerted, it is not running — it is just not stopped.

11. Further reading & tools

• Taught: T05-L04 · Making an automation safe to fail - supplies durable identity, terminal failure states, idempotent effects, circuit breaking, and reconciliation.
• Taught: T12-L05 · Governance, evidence and handover - supplies ownership, data boundaries, retention, risk records, and the substitute-operator expectation.
• Taught: n8n monitoring (opens in a new tab) - primary documentation for health and metrics available from a self-hosted n8n instance.
• Taught: n8n execution data (opens in a new tab) - primary guidance for attaching searchable business data to executions.
• Taught: Langfuse observability (opens in a new tab) - primary tracing model for requests and nested model or tool observations.
• Taught: Langfuse token and cost tracking (opens in a new tab) - primary guidance for ingested or inferred usage and cost.
• Catalogued: Langfuse alerts (opens in a new tab) - current threshold, no-data, notification, and recovery behaviour; a separate enforcement control is still required for a hard cap.
• Catalogued: n8n OpenTelemetry tracing (opens in a new tab) - current primary guidance for exporting workflow and node traces.
• Catalogued: Uptime Kuma notification methods (opens in a new tab) - project documentation for availability-monitor notification integrations.
• Catalogued: Tools index - compare monitoring and tracing tools only after defining identities, signals, response, retention, replay, and enforcement.