Understanding the Front-Commerce Cloud monitoring dashboard

Learn how to read and interpret the Front-Commerce Details dashboard to monitor your project's performance, diagnose issues and understand resource consumption.

This guide explains each section of the Front-Commerce Details dashboard available on the monitoring platform. For access instructions, see How to visualize traffic and metrics.

How requests flow through the infrastructure​

Before diving into the dashboard, it helps to understand how a request travels through the Front-Commerce Cloud infrastructure:

1. Nginx Ingress — receives all incoming HTTP requests from end-users
2. Varnish — an HTTP cache layer that serves cached responses when possible
3. Front-Commerce (Node.js) — the application server that renders pages
4. External services — backends called by Front-Commerce (e-commerce platform, search engine, CMS, etc.)

The HTTP Tunnel panel in the Ingress section visualizes this entire chain, showing the request rate at each stage. A large gap between two stages indicates where requests are being absorbed (e.g. by the Varnish cache) or where a bottleneck exists.

Filters​

At the top of the dashboard, you can filter data using:

• Cluster — select the Kubernetes cluster
• Namespace — select your project environment (e.g. fcc-my-project)
• Target — filter outbound requests by destination service
• Pod — focus on a specific Front-Commerce pod

Ingress stats​

Question it answers: What traffic is the application receiving?

This section shows all HTTP requests entering the platform through the Nginx Ingress controller.

Key panels​

• Ingress requests — request rate (req/s) split by HTTP status code. Colors follow standard conventions: green for 2xx, blue for 3xx, orange for 4xx, red for 5xx.
• Ingress count by status — a donut chart showing the proportion of each status code over the selected time range. Useful to quickly spot an abnormal ratio of errors.
• Ingress errors — request rate for 5xx errors only. Any sustained value above zero deserves investigation.
• 200 - Response time (ms) — average response time for successful requests.
• Mean 200 response time — a gauge showing the average response time. The color goes from green to red as it approaches 1500 ms.
• Response time for non-200 statuses — response time for redirects, client errors, etc. Useful to detect slow error pages or misconfigured redirects.
• HTTP Tunnel — request rate at each stage of the infrastructure (nginx ingress → varnish front → varnish back). See the architecture section above.

Outbound requests distribution​

Question it answers: How fast are remote services responding?

This section shows the response time distribution of outbound requests made by Front-Commerce to external services (e-commerce backend, search engine, CMS...). Each target service gets its own panel.

Responses are grouped into time buckets:

• 0s–1s (green) — fast, healthy responses
• 1s–2s (yellow) — getting slow
• 2s–5s (orange) — slow, may impact user experience
• 5s+ (red) — very slow, likely causing timeouts or degraded experience

A healthy service should show mostly green. If orange/red bands grow, the external service is slowing down and may need investigation.

Outbound requests volumes​

Question it answers: How many requests is Front-Commerce making to external services?

This section uses the same time buckets as above but shows volumes (req/s) instead of proportions. It helps identify:

• Traffic spikes after a deployment or cache flush
• Unusual request volumes that may indicate a caching issue or a retry loop

Varnish cache​

Question it answers: How efficient is the HTTP cache layer?

This section monitors the Varnish reverse proxy that sits between Nginx and Front-Commerce.

Key panels​

• Varnish cache efficiency — a stacked area chart showing the proportion of each response type:

  • hit (green) — served from cache, best case
  • grace (yellow) — served from cache while refreshing in the background
  • miss (red) — cache expired, request forwarded to Front-Commerce
  • pass (blue) — uncacheable request (e.g. authenticated pages)
  • piped — tunneled directly to backend
  • synth — response crafted by Varnish itself
  • drop (dark red) — dropped request, should be zero

  A healthy project should have a high proportion of hit + grace.

• Varnish bans — cache purge requests over time. Spikes correspond to cache invalidations triggered by your application or team.

• Cache hit/miss repartition — raw hit vs miss rate.

• Varnish Usage — compares total ingress queries to queries served by Varnish. The gap represents the load absorbed by the cache.

• CPU / Memory usage — resource consumption of the Varnish container. Monitor these to ensure the cache layer has enough resources.

• LRU Nuke Operations — when Varnish runs out of memory, it evicts objects (nukes). Frequent nukes indicate the cache memory is too small.

• Cached objects count — number of objects stored in Varnish.

Per component details​

Question it answers: How are the individual components performing?

This section is organized in three columns:

For each component, you will find:​

• CPU usage — stacked by pod. Thresholds at 1 CPU (orange) and 1.5 CPU (red). Sustained usage near the limit may cause throttling.
• Memory usage and limit — memory consumed vs allocated limit (shown as a red dashed line). If memory approaches the limit, the pod risks being killed (OOMKilled).
• Network bandwidth — bytes received and transmitted per second.
• Disk bandwidth — read/write throughput.
• Resources — a summary showing the CPU request, memory request, and memory limit allocated to the component.

Front-Commerce specific​

• Number of pods — current pod count and total CPU usage. A drop in pod count may indicate restarts or scaling issues.
• CPU usage by pod — non-stacked view to compare individual pods. If one pod uses significantly more CPU, it may indicate an uneven load distribution.
• Network packets rate — includes dropped packets and errors. Non-zero values for dropped/error metrics indicate network issues.

Redis specific​

• Number of keys — tracks the key count in Redis cache and Redis sessions. A sudden spike may indicate a cache issue. A growing session count may indicate sessions are not expiring properly.
• Commands — command rate by type (GET, SET, DEL, etc.). Helps understand the cache or session access patterns.
• Uptime — Redis uptime in seconds. A reset to zero indicates a restart.
• Storage usage (cache only) — persistent volume usage vs capacity.

NodeJS​

Question it answers: Are there low-level runtime issues in the Node.js process?

• EventLoop Lag — time spent in garbage collection, by type. High values indicate the Node.js event loop is being blocked, which degrades response times.
• Heap size usage — V8 heap memory consumption by space (new, old, code, etc.). A continuously growing old space may indicate a memory leak.

Tips​

• Use the time range selector (top right) to zoom into specific periods.
• Hover over any graph to see exact values at a specific point in time.
• Use the namespace selector to switch between staging and production environments.
• Correlate spikes across sections: a response time increase in Ingress stats often has a root cause visible in Outbound requests or Per component details.