Incident-first observability for your apps and your AI
Stop switching tools. Start closing incidents.
APM on one side, AIPM on the other, the incident in the middle.
Incident workflow
Who is on for each product right now, and who covers when they are out.
Severity, status, assignee, ordered updates and the linked alerts, on one page.
Armed within sixty seconds of saving. A firing rule opens the incident.
APMApplication observability
One dataset: from the slow trace to the log line that names the cause.
P95, error rate and requests across every product, at a glance.
Every hop from the Python one-liner: database, HTTP, cache and queue.
Where in the request it failed, with the stack trace.
Thousands of identical errors into one group, with an owner.
One root cause, one page, one owner.
A stack frame linked to its line on GitHub.
Kubernetes and infrastructure metrics, visible and alertable.
Anomaly alerts that learn normal, with no thresholds to tune.
Whether the incident function is actually working, in numbers.
AIPMAI observability
Tokens from the provider, cost computed server-side, per model, product and environment.
Budgets, allocation and a forecast.
What the company actually uses, including keys nobody registered.
Agent, step and tool spans in the same tree as the request that started them.
A stuck agent becomes an incident.
Every AI call in the organisation, with no code change.
Thumbs and comments linked to the exact request that produced them.
Quality regressions become incidents.
PII, injections and refusals, filed into the incident queue.
Platform & security
The key decides tenant, product and environment. Python needs one line.
The page reaches people where they already work, and every action is logged.
Scanner findings and platform misuse, filed into the same queue.
Every key minted, role changed and incident resolved, streamed or pulled.
SAML SSO for every organisation, owner and member roles, isolation audited three times.
Six screens, in the order an incident actually runs.
The on-call opens the platform and knows in thirty seconds what is wrong and who owns it.
liveThe request, the agent that handled it, every tool it called and every model call inside them: one waterfall, parent to child.
The waterfall is live for every request today, with an exception marker and the stack trace on the failing span.
Trace waterfall liveException marker live
Ask Claude, ChatGPT, Cursor or any other agentic tool what is open and who has it, and get the answer from live incident data.
Things to ask
Python and Node.js in one line today, Go next. Every other language through its OpenTelemetry exporter, same key.
$ pip install indratrace
from indratrace import init_observability init_observability(api_key="it_live_…") # that's it: HTTP spans, model tokens and logs, one trace tree
$ npm install indratrace
INDRATRACE_API_KEY="it_live_…" \ node --import indratrace/register app.js # that's it: HTTP spans, model tokens and logs, one trace tree
# any OpenTelemetry SDK or the Collector: the same key, as an OTLP header OTEL_EXPORTER_OTLP_HEADERS="x-indratrace-key=it_live_…"
Plain OTLP over HTTP, and the SDK is Apache-2.0. The whole configuration is one API key. No endpoint, no product name, nothing else to set: the key says which product, which environment, and whose.
Log files, Kubernetes and cloud metrics through the OpenTelemetry Collector with the same key.
Notify the team where it works, take scanner findings in as incidents, and stream the audit trail to your SIEM.
Out to where the team already works.
Scanner findings, filed as incidents.
The audit trail, streamed to your SIEM.
Pull the audit trail on your schedule, from behind your firewall.
Most platforms are a dozen products on a dozen meters. IndraTrace is one incident, one meter, one key.
| Typical observability platform | IndraTrace | |
|---|---|---|
| Pricing | Per host, plus a meter for each product | A platform fee plus what you ingest |
| Where an incident lives | A separate product beside the dashboards | The front page, with the on-call assigned automaticallylive |
| AI calls | An add-on, metered in its own credits | The same trace tree as the request, with cost per calllive |
| Languages | A vendor agent per language | OpenTelemetry-native, one keylive |
| Security findings | A different tool and a different queue | Incidents with owners, in the same queuelive |
| AI assistant access | An assistant inside their own screens | An MCP connector with scopes and auditcoming |
| Setup | An agent on every host | One line in the app, or one Collector keylive |
Encryption, isolation, access and retention: what your security review asks, on the page.
A flat platform fee, then ingest and retention by the gigabyte. The meter is on the page, not in a sales call.
Straight answers on setup, pricing, security and what is coming next.
No. Python and Node.js are one line with auto-instrumentation, and Java, .NET, Go, Ruby and PHP send through their standard OpenTelemetry exporter with the same key.
Most platforms are a dozen products on a dozen meters. IndraTrace is one incident, one meter, one key: the incident is the front page, the bill is a platform fee plus what you send, and setup is one line.
IndraTrace is a hosted service. Each organisation's data is isolated from every other's, with that isolation audited three times; it is encrypted in transit and at rest, and kept for the retention your organisation sets.
Agent runs are traced today. An MCP connector for AI assistants is coming: read incidents, acknowledge and annotate with scopes, and every action audited.
Three lines on one bill: a platform fee, ingest by the gigabyte above what the fee includes, and retention if you keep data longer than the included window. Unlimited team members, and nothing per host.
No. One line in the app, or one key in the OpenTelemetry Collector for log files. Kubernetes and cloud metrics through the same Collector and key are coming.
Findings from GitHub, GitLab, Snyk and SonarQube post in as security incidents with an owner, in the same queue as operational ones. Wiz and CrowdStrike are coming.
