Know which step was slow. Not just that the run was.
Logs, metrics, and traces in one place, emitted as OpenTelemetry as standard. When an integration takes four seconds instead of one, the trace already shows you which call spent the time.
- Metrics
- Traces
- Alerts
- Selective logging
- payroll-sync4.21s
- Schedule12ms
- Query · employees460ms
- Data Mapper240ms
- REST Client · Workday2.6s
- Upsert · NetSuite510ms
- Send To Engage230ms
Three signals, one standard, every plan
Logs, metrics, and traces are emitted as OpenTelemetry — the open standard your monitoring stack already speaks. Point them at the tools you have, or use the dashboards built in. Part of the platform, not a separately priced add-on.
Is it healthy?
Throughput, latency, and error rates per integration and per tenant. The numbers that tell you something changed before anyone files a ticket.
Where did the time go?
Each run broken into spans, with the duration of every activity. A slow integration stops being a mystery and becomes a specific call to a specific system.
What actually happened?
Structured output from every step, at the level you chose, routed to the logger you named — not one undifferentiated stream.
Because it is OpenTelemetry rather than a proprietary format, none of this locks you in. The same data flows to whatever you already use to watch the rest of your estate.
Nobody watches a dashboard at 3am
Dashboards answer questions you thought to ask. Alerts tell you about the ones you did not. Koodisi pushes the failure to the people who own it, through the channels and the service desk they already work in.
- Alerts
- Be told when a run fails or a deployment does not land, rather than finding out when someone downstream notices the data is wrong.
- Escalation
- A failure nobody acknowledges should not sit unowned. Escalation moves it along until somebody picks it up.
- ITSM integration
- Route incidents into the service desk your organisation already runs, so integration failures follow the same process as everything else.
Incident management is available on paid plans.
A run fails in production
- On-callIntegration platform teamImmediately
- Service deskIncident raised in ITSMImmediately
- EscalationEngineering managerUnacknowledged 15m
Everything logged is nothing found
A log that records every step at every level is as unhelpful during an incident as no log at all. You choose what each step writes, where it goes, and which values are reduced on the way.
Log at the level the environment needs
Run Debug while you are building and drop to Warn in production, without editing the workflow's logic to do it.
Route to named loggers
Give a Log step a logger name and its output separates from everything else, so noisy diagnostics from one integration stay out of the stream your on-call team watches.
Mask the field, keep the record
Fields you designate as sensitive are reduced before they are written — an account number down to its last four digits — while the rest of the payload stays readable enough to debug.
From the blog
FAQ
Questions about observability
What is emitted, who gets told, and where it stops.
Still have a question? Talk to an expert.
OpenTelemetry. Logs, metrics, and traces are emitted as OTel, so the same data can flow into whatever you already use to watch the rest of your estate rather than being trapped in one vendor's dashboard.
No. Real-time metrics and OpenTelemetry observability are part of the platform, not a separate product, because you cannot run an integration platform you cannot see into. Log retention is set to match your compliance needs.
The run broken into spans, with the duration of each activity. When an integration takes four seconds instead of one, the trace shows which call spent the time rather than leaving you to reconstruct it from timestamps.
Incident management covers alerts, escalation, and integration with the service desk your organisation already runs, so a failure is pushed to whoever owns it. It is available on paid plans.
Every Log step writes at a level you choose — Debug, Info, Warn, or Error — and can be routed to a named logger. Run Debug while building and drop to Warn in production without changing the workflow's logic.
Observability tells you what happened. Koodisi Engage helps you fix it. Metrics and traces answer 'did it fail, and where'; Engage holds the failed records themselves, with retry, fallout management, and somewhere for a person to resolve them.
Seeing the failure is half of it.
Koodisi Engage owns the other half — retry, fallout management, and somewhere for a person to resolve what could not clear itself.
How recovery works