Server Timing Monitoring

⚙️ Server Timing Monitoring

GermainUX collects server-side performance metrics returned with HTTP responses through the standard Server-Timing header. These metrics help teams understand how back-end processing contributes to the response time experienced by real users.

🔎 Monitoring components

How it works

The monitored server adds performance metrics to an HTTP response:

Server-Timing: database;dur=120, application;dur=75, cache;dur=8

In this example:

GermainUX collects the available metrics and associates them with the corresponding browser request, page, user, and session.

The metric names and values are produced by the monitored server. GermainUX cannot provide server-processing breakdowns when the application does not return them.

Capabilities

GermainUX can:

• Collect metrics exposed through the Server-Timing response header.

• Associate each server metric with its originating HTTP request.

• Compare browser-request duration with the available server-processing duration.

• Analyze individual server phases such as application, database, cache, or integration processing.

• Restrict collection to approved Server Timing metric names.

• Organize related metrics into an application-specific hierarchy.

• Use a custom extractor when the default Server Timing extraction does not meet the application’s requirements.

• Correlate Server Timing data with users, sessions, pages, workflows, errors, and other browser activity.

• Use the JS Profiler for deeper investigation of the browser and JavaScript activity surrounding a slow request.

Default monitoring

No GermainUX customization is required when the server returns standard Server Timing headers and all exposed metrics should be collected.

Business benefits

Server Timing Monitoring helps organizations:

• Determine whether a slow user interaction is caused by browser, network, or server processing.

• Identify which server-side operation contributes most to a request’s duration.

• Find database, application, cache, or integration bottlenecks visible to real users.

• Prioritize back-end problems according to affected users and business workflows.

• Reduce the time required to correlate browser complaints with server performance.

• Compare server performance across pages, APIs, releases, and user populations.

• Validate whether a server-side correction improved the actual user experience.

Continuous monitoring

GermainUX RUM JS or the GermainUX RUM Extension collects Server Timing metrics as part of browser Network Request Monitoring.

Use:

• RUM JS when the GermainUX monitoring script can be deployed directly in the application.

• RUM Extension when direct script deployment is unavailable or access to the required browser context requires an extension.

The browser and monitored service must make the Server Timing information available to the page. Cross-origin services may require appropriate response-header and resource-timing access configuration.

Deeper investigation with JS Profiler

When Server Timing identifies a slow request, the GermainUX JS Profiler can provide additional browser-side evidence, including:

• JavaScript functions associated with the request.

• Function execution time.

• Network requests and resource loading.

• Long-running browser tasks.

• JavaScript errors and stack traces.

• Browser events and user interactions.

• DOM and rendering activity.

• Application, page, workflow, and session context.

The JS Profiler complements Server Timing Monitoring. It does not create missing server-side measurements; those must be generated by the responding application or service.

Analytics

GermainUX can analyze Server Timing metrics through KPIs, measures, pivots, trends, drill-through views, and session context.

GermainUX users can create watches to receive notifications when collected Server Timing insights meet conditions of interest.

Server configuration

Instrument the applicable application, API, proxy, or service to return a valid Server-Timing response header.

For example:

Server-Timing: database;dur=120;desc="Database query",
 application;dur=75;desc="Application processing"

Use stable metric names so GermainUX can consistently aggregate and compare measurements over time.

Do not include sensitive information in metric names or descriptions.

Enable or disable monitoring

Server Timing Monitoring is controlled through Network Request Monitoring.

To change its status:

1. Go to Germain Workspace > Analytics > UX Monitoring Profiles.

2. Select the applicable profile.

3. Select or clear Network Requests Monitoring.

4. Save the profile.

Disabling Network Request Monitoring also prevents the collection of Server Timing metrics associated with those requests.

Collect selected metric types

By default, GermainUX collects all available Server Timing metric names. Use allowedTypes to restrict collection to approved metrics:

const settings = germainApm.getDefaultSettings();

settings.plugins.network.serverSideTimingsMonitoring = {
  enabled: true,
  allowedTypes: [
    "application",
    "database",
    "cache"
  ]
};

germainApm.start(settings);

Metric names must match those returned in the Server-Timing header.

Disable Server Timing collection only

Server Timing collection can be disabled without disabling all network-request monitoring:

const settings = germainApm.getDefaultSettings();

settings.plugins.network.serverSideTimingsMonitoring.enabled = false;

germainApm.start(settings);

Network requests can continue to be monitored without their Server Timing breakdown.

Metric hierarchy

Use typesHierarchy when application-specific Server Timing metrics need to be organized into logical groups:

const settings = germainApm.getDefaultSettings();

settings.plugins.network.serverSideTimingsMonitoring = {
  enabled: true,
  typesHierarchy: {
    backend: [
      "application",
      "database",
      "cache"
    ]
  }
};

germainApm.start(settings);

The hierarchy should reflect the metric names and organization used by the monitored application.

Custom extraction

Use a custom extractor when Server Timing values require application-specific processing:

extractor?: (
  entry: PerformanceResourceTiming,
  event?: NetworkMonitoringEvent
) => ServerTiming[];

A custom extractor can normalize metric names, select specific values, or adapt nonstandard application behavior. Use it only when the default extraction is insufficient.

Privacy and security

Server Timing headers are visible to the browser and may be visible to users through browser developer tools.

When defining server metrics:

• Do not expose credentials, tokens, internal hostnames, database statements, personal information, or secrets.

• Use general and stable metric names.

• Avoid revealing unnecessary infrastructure details.

• Restrict cross-origin exposure appropriately.

• Review metric descriptions for sensitive information.

• Apply the organization’s security and compliance requirements.

Server Timing should expose performance measurements—not confidential diagnostic content.

Recommended investigation workflow

1. Use RUM JS or the RUM Extension to identify a slow browser request.

2. Review the Server Timing breakdown returned for that request.

3. Determine whether the delay occurred in the application, database, cache, integration, or another exposed server phase.

4. Identify the affected users, sessions, pages, and business workflows.

5. Correlate the request with Session Replay, errors, and other browser activity.

6. Use the JS Profiler when deeper browser or JavaScript evidence is required.

7. Review corresponding server-side monitoring, logs, or transactions when available.

8. Correct the responsible application component or dependency.

9. Validate the correction through continuous Server Timing and Network Request Monitoring.

Deployment and configuration

ℹ️ Get Help

The Germain Team can help you set this up. Contact GermainUX Support.