​

Observability

Notifizz emits enough signal to follow any single delivery from event acceptance to bell update — the trick is knowing where to look. This page covers the customer-side observability surface: correlation IDs, the dashboard’s tracing views, AI usage observability.

​

TL;DR

• Correlation ID stamped at message creation time — propagates through every queue hop and inbox write.
• Per-workflow-instance trace in the dashboard — every step (orchestrator, enricher, channel) with timing.
• AI usage observability — see which campaign / user consumed how many AI credits.
• Implementation tasks — proactive surfacing of orchestrator issues before they hit prod.

​

Correlation IDs

Every notification carries a correlation id stamped at message creation time. The id propagates through:

• The workflow instance that created it.
• Every queue hop (the internal queue stages).
• The delivery record.
• The widget delivery (visible in the message detail).

Use it to trace one delivery end-to-end:

1. Find the correlation id in the dashboard delivery history (per-message detail view).
2. Open the workflow trace it belongs to — every step, its inputs and outputs, and the point where the chain stopped.
3. If the trace doesn’t explain it, share the correlation id with Notifizz support. It designates that one delivery exactly, which is what keeps the round-trip short.

The id format is opaque (UUID-like). It’s stable across retries — a retried delivery keeps the same correlation id.

​

Workflow trace

Every workflow instance gets a trace view in the dashboard:

• Steps in execution order — initial event match, orchestrator code, enricher calls, channel dispatch.
• Timing per step — useful to spot the slow link (usually a cold enricher or a slow channel render).
• Inputs and outputs at each boundary — the orchestrator’s recipient list, the enricher’s params and response, the rendered template.
• Errors with stack traces (for orchestrator code) or typed error codes (for enrichers, channels).

This is the first place to look for “my event reached Notifizz but no notification fired” — the trace shows where the chain broke.

​

Implementation tasks

Implementation tasks are proactive — the dashboard surfaces orchestrator issues at edit time, before they hit traffic: Resolution is mostly automatic — the AI proposes fixes, you accept or edit.

​

AI usage observability

The AI authoring layer (orchestrator codegen, implementation-task auto-resolution) consumes credits. The dashboard shows:

• Per-user usage — how many credits each team member consumed.
• Per-campaign usage — which campaigns required the most AI work to author.
• Per-action breakdown — codegen vs review vs implementation-task resolution.

Credits are pooled daily per organisation, with a soft cap that slows new AI requests rather than blocking them when the pool is exhausted.

​

”My event didn’t fire” — checklist

​

”My campaign didn’t run” — same checklist, deeper

If the workflow instance was created but no notification reached the user:

• Recipient resolution — orchestrator returned empty list, or returned a recipient with missing email.
• Channel config — the campaign references an NC config that no longer exists, or an email config without verified sending domain.
• Variable rendering — the template references a variable that didn’t resolve.
• Provider-side rejection — for email, the provider may reject deliverability (bounce, complaint history).

Each shows up in the workflow trace.

​

”My enricher times out” — what next?

In the workflow trace, locate the enricher step. Three signals: See enrichers tutorial for the full debugging matrix.

​

FAQ

​

See also