📊 GermainUX Transaction Monitoring Overview
GermainUX provides real-time insight into the performance, behavior and outcome of monitored transactions.
A transaction can represent a user interaction, web-service call, REST API request, application method, database query, business-process step or other timed activity. GermainUX helps teams understand not only that a transaction was slow or failed, but where time was spent, which component was responsible and which users or business processes were affected.
🔎 What Transaction Insights Help You Understand
Transaction analysis can answer questions such as:
|
Question |
|---|
|
How long did the transaction take? |
|
Which layer consumed the most time? |
|
Did the delay occur in the browser, network, application, integration or database? |
|
Which code, method, query or external service caused the slowdown? |
|
Why did the transaction fail? |
|
Which users, sessions or workflows were affected? |
|
Is the issue isolated or recurring at scale? |
|
Did performance change after a release or configuration update? |
⚙️ Core Capabilities
|
Capability |
Purpose |
|---|---|
|
Real-Time Code Profiling |
Analyzes application-code execution continuously to identify slow methods, performance hotspots, exceptions and inefficient resource use. See Code Profiling. |
|
Real-Time Correlation and Tracing |
Connects related events and transactions across application layers and data sources. See Transaction Tracing. |
|
Time Breakdown |
Separates the total response time into the layers and child transactions that contributed to it. |
|
Error Analysis |
Captures failures and their surrounding context to identify root cause and user impact. |
|
Segmentation |
Compares transaction behavior by application, page, user, location, browser, server, version or other pivot. |
|
User and Workflow Context |
Connects technical activity with the user session, application action or business process that initiated it. |
➡️ End-to-End Transaction Analysis
Depending on the monitored application and enabled components, GermainUX can trace a transaction across layers such as:
User interaction → Browser → Network → Web server → Application code → Integration or API → Database or backend service
This connected view helps teams move from:
“The transaction is slow.”
to:
“The transaction is slow because this application method is waiting on this API, which is delayed by this database query.”
Details on how to correlate transaction from various data sources.
⏳ Time Breakdown
GermainUX can break down transaction duration by layer, component and child activity.
Common layers include:
|
Layer |
Example evidence |
|---|---|
|
Browser |
JavaScript execution, rendering and user-perceived wait time |
|
Network |
Request transfer and connection latency |
|
Web server |
Request handling and queueing |
|
Application |
Methods, services and code execution |
|
Integration |
API, middleware and external-service calls |
|
Database |
Queries, locks, waits and processing time |
The exact layers depend on the monitored transaction and available telemetry.
🖱️ User Click Transactions
GermainUX can analyze a user click as an end-to-end transaction rather than an isolated input event.
For a monitored click, the platform can correlate:
|
Item |
|---|
|
The element selected by the user |
|
Browser and page activity |
|
Synchronous and asynchronous requests |
|
Network latency |
|
Application and integration activity |
|
Errors and exceptions |
|
Related database or backend activity |
|
The next visible outcome experienced by the user |
This makes it possible to determine whether a slow click was caused by the interface, browser, network, backend code, external integration or database.
User Click analysis can also be connected with Session Replay to show what the user experienced before, during and after the transaction.
☁️ Web-Service Transactions
GermainUX can monitor stateful and stateless web-service calls, including SOAP-based integrations.
Transaction insights can include:
|
Attribute |
|---|
|
Service and operation name |
|
Endpoint |
|
Start time and duration |
|
Request and response status |
|
Error or fault details |
|
Correlation identifiers |
|
Parent and child transactions |
|
Calling and target systems |
|
Available request or response metadata |
When configured and permitted by the organization's privacy policy, relevant SOAP request or response details can be retained for troubleshooting. Sensitive fields can be masked, excluded or otherwise protected according to the monitoring configuration.
📨 REST API Transactions
GermainUX can monitor stateless REST API calls using standard HTTP methods, including:
|
Method |
|---|
|
|
|
|
|
|
|
|
|
|
REST transaction data can include:
|
Data |
|---|
|
Method and URI |
|
Endpoint and target service |
|
Status code |
|
Duration |
|
MIME or content type |
|
Request and response size |
|
Error details |
|
Correlation identifiers |
|
Available JSON, XML or other payload context |
Payload capture is configurable. Sensitive data should be masked, excluded or omitted according to security, privacy and compliance requirements.
📃 Code-Level Analysis
When Code Profiling is enabled, GermainUX can connect a transaction to the code that executed it.
Depending on the monitored technology, analysis can include:
|
Analysis |
|---|
|
Slow methods |
|
Method call hierarchy |
|
Exclusive and cumulative duration |
|
Exceptions and stack traces |
|
CPU or memory impact |
|
Database calls |
|
External-service calls |
|
Repeated or inefficient execution |
This helps developers identify the specific code path responsible for a poor transaction rather than relying only on high-level response times.
🔗 Correlation and Distributed Tracing
GermainUX can correlate transactions using mechanisms such as identifiers, exact matching and streaming relationships.
Common correlation fields include:
|
Field |
|---|
|
Session ID |
|
Request or transaction ID |
|
Correlation ID |
|
Trace or span ID |
|
User ID |
|
Business-object ID |
|
Order, case or service-request number |
|
Timestamp and source-target relationship |
Correlation can connect telemetry collected from different applications, technologies or monitoring components into one transaction timeline.
❌ Transaction Errors and Failures
When a transaction fails, GermainUX can help determine:
|
Question |
|---|
|
What failed |
|
Where the failure occurred |
|
Which error or exception was generated |
|
What happened immediately before the failure |
|
Which parent and child transactions were involved |
|
Which user, session or business process was affected |
|
Whether the same failure affects other transactions |
|
Whether the issue is new or previously known |
Errors can be prioritized by frequency, user count, workflow impact and business outcome.
More details on Error Analysis.
📈 Analyze Transactions at Scale
Transaction data can be aggregated and segmented using measures and pivots.
Common measures include:
|
Measure |
|---|
|
Count |
|
Error or failure count |
|
Average duration |
|
Minimum and maximum duration |
|
Total duration |
|
50th, 90th, 95th, 99th and 99.9th-percentile duration |
|
Throughput |
|
Success and failure rate |
Common pivots include:
|
Pivot |
|---|
|
Application and component |
|
Transaction or operation name |
|
Endpoint and HTTP method |
|
User, role, group and location |
|
Browser, device and operating system |
|
Server, environment and version |
|
Error category |
|
Calling and target system |
|
Business object or workflow |
Percentiles are particularly useful because an acceptable average can hide serious delays affecting a smaller population.
🖱 Analyze Transaction Performance in the Analysis Dashboard
The Analysis Dashboard is the primary place to investigate the performance of a monitored transaction. It brings aggregate behavior, related signals, segmentation and instance-level evidence into one investigation.
Open the Analysis Dashboard by drilling into the transaction KPI from an Aggregate, Pivot or Drill-through Dashboard. The selected KPI, time range, filters and analytical scope are carried into the investigation.
Determine Whether Performance Is Abnormal
The Analysis Dashboard compares the selected transaction measure with its historical or configured baseline.
Use this view to determine:
|
Question |
|---|
|
Whether transaction performance is actually degraded |
|
When the degradation started |
|
How current performance compares with the baseline |
|
Whether the issue affects the average, a percentile or only isolated instances |
|
Whether the behavior represents a spike, sustained regression or outlier |
For transaction performance, the 95th or 99th percentile is often more informative than the average because it exposes serious delays affecting a smaller population.
📈 Review Related KPIs
The Related KPIs section surfaces configured signals that may help explain the transaction's behavior.
Examples include:
|
KPI |
|---|
|
Browser or JavaScript activity |
|
Outbound HTTP requests |
|
API and integration calls |
|
Application errors and exceptions |
|
Database queries and waits |
|
CPU, memory or infrastructure utilization |
|
Deployment or configuration events |
|
User and workflow activity |
Related KPIs are evaluated for factors such as deviation, direction, relationship type, expected strength and co-movement with the transaction KPI. This helps investigators focus on the signals most relevant to the slowdown or failure.
Select a related KPI to compare its full trend with the primary transaction. Related events configured as markers can appear directly on the transaction timeline.
More details on Related KPIs.
💡 Identify Leading Factors
The Segmentation Breakdown groups transaction performance by available pivots and highlights the segments most associated with the current behavior.
Leading Factors can identify concentrations such as:
|
Factor |
|---|
|
A specific endpoint or operation |
|
An application page or component |
|
A browser, device or operating system |
|
A server, environment or application version |
|
A user group, role or location |
|
An error category |
|
A calling or target system |
Segments can be identified as Degraded, Better, Spike, Outlier or New relative to their baseline.
This helps distinguish a widespread problem from one isolated to a particular endpoint, release, user population or technical component.
More details on Leading Factor.
📄 Open an Individual Transaction
After identifying an affected segment, open a representative transaction instance for detailed analysis.
Instance Analysis can provide:
|
Item |
|---|
|
Transaction duration and status |
|
Duration breakdown by layer or child activity |
|
Transaction attributes and identifiers |
|
Parent, child and related transactions |
|
Errors and exceptions |
|
Request, response and endpoint context |
|
Application-code execution when Code Profiling is enabled |
|
Related KPIs within the selected instance |
Use the identifiers and attributes to confirm that all displayed activity belongs to the same transaction, session or business process.
🕓 Follow the Trace Timeline
The Trace Timeline displays the ordered activity associated with an individual transaction.
Depending on available telemetry, it can show:
User Click → Browser Activity → HTTP Request → Application Method → API or Integration → Database Query
Use the Trace Timeline to determine:
|
Question |
|---|
|
Which activity occurred first |
|
Which calls executed inside the transaction |
|
Where the critical path spent the most time |
|
Whether activities were sequential or overlapping |
|
Which child transaction failed or became slow |
|
Which component should be investigated or assigned for resolution |
More details on Trace Timeline of the Analysis Dashboard.
⏯️ Replay the User Experience
When the transaction originated from a monitored user session, open Session Replay to see what the user experienced before, during and after it.
Session Replay can reveal:
|
Item |
|---|
|
What the user was trying to accomplish |
|
The interaction that initiated the transaction |
|
Whether the interface appeared frozen or unresponsive |
|
Which error or message the user saw |
|
Whether the user retried, abandoned or completed the task |
This connects the technical trace with its actual user and business impact.
More details on Session Replay.
🚀 Move from Analysis to Action
The Analysis Dashboard helps teams move through one continuous workflow:
|
Step |
Action |
|---|---|
|
1 |
Confirm that transaction performance is abnormal. |
|
2 |
Identify the related KPIs that changed with it. |
|
3 |
Find the endpoints, users, environments or components where the issue is concentrated. |
|
4 |
Open a representative transaction instance. |
|
5 |
Follow its Trace Timeline and duration breakdown. |
|
6 |
Replay the associated user session when available. |
|
7 |
Identify the likely root cause and responsible component. |
|
8 |
Create an alert, report, ticket or automated action when appropriate. |
🛠️ Typical Investigation Workflow
|
Step |
Action |
|---|---|
|
Detect |
Detect a slow, failed or abnormal transaction. |
|
Quantify |
Quantify the number of occurrences and affected users or workflows. |
|
Compare |
Compare the current result with its baseline or historical behavior. |
|
Segment |
Segment the issue using relevant pivots. |
|
Trace |
Trace the transaction across its parent, child and dependent activities. |
|
Profile |
Profile the application code when code-level telemetry is available. |
|
Inspect |
Inspect errors, requests, responses and technical context. |
|
Replay |
Replay an affected user session when applicable. |
|
Identify |
Identify the root cause and responsible component. |
|
Respond |
Alert, report or automate the appropriate response. |
🔒 Data Privacy and Security
Transaction monitoring can contain sensitive technical or business data. Configure collection according to organizational requirements.
GermainUX can be configured to:
Exclude selected headers, fields or payloads; Mask or anonymize sensitive values; Restrict access to transaction details; Apply retention policies; Avoid storing request or response bodies when they are unnecessary.
|
Option |
|---|
|
Exclude selected headers, fields or payloads |
|
Mask or anonymize sensitive values |
|
Restrict access to transaction details |
|
Apply retention policies |
|
Avoid storing request or response bodies when they are unnecessary |
Collect only the data needed to diagnose and improve the monitored transaction.
More details on Data Privacy and Security.