@servicetitan/journey
v4.2.0
Published
Critical user journey monitoring — reports good/bad/excluded verdicts to Datadog RUM as a custom action
Readme
@servicetitan/journey
Critical user journey monitoring for Datadog RUM (user_journey custom actions).
- Docs: Journey (source:
packages/docs/docs/journey.mdx)
Prefer defineJourney handles (.start / .step / .complete). Soft ambient attributes HTTP only when exactly one step is in flight — pass { stamp: step.stamp() } after await or when steps overlap. start() always opens a new instance. Default aborted-request policy is continue.
Kibana links on journeys
Open context.journey.kibana_url, regardless of the journey's outcome or failure reason.
kibana_scope: request: the identified request that caused an HTTP-scored failure. Its ID is also infailed_request_id. Existing precise links are unchanged.kibana_scope: related_logs: a search for this tenant and username/email during the journey, with a one-minute buffer. This covers step errors, timeouts, network failures without a response, and good/excluded journeys when host user context exists.kibana_scope: related_requests: captured requests when host user context is unavailable. These requests are context, not proof that they caused the failure.
Every retained response with a readable cf-ray also has its own
steps[].requests[].kibana_url, including successful responses. The existing limits
remain: five requests per step and 20 across the event, with requests_truncated flags.
The feature adds no network calls or changes to scoring, thresholds, or transport behavior.
Supported origins are https://go.servicetitan.com and production Enterprise Hub
monolith hosts (https://<tenant>.eh.go.servicetitan.com), verified against the same
production log view. Other origins are not assumed to share that log contract.
Ignored/aborted requests are not captured. Cross-page serialization does not carry
request history from the previous page.
Related-log searches read tenant and name/email from the host RUM getUser().
Those existing identity values are included in the link's query; request URLs, bodies,
and other headers are not collected. Missing identity never falls back to all tenants.
Without usable user context or any captured request IDs, no safe link can be built.
Frontend-only failures and requests that never reached the app may have no backend logs.
The existing usr.kibanaUrl is untouched. Links are event details, not metric tags.
The updated package must be published, adopted, and deployed by the host. Separately bundled MFEs also need an updated owning runtime to retain request details. Browser click-through and Datadog display still require rollout verification; Kibana access is required to view logs.
