Written from your Monitoring note for the interview on 14 October 2026. The questions are general ones about monitoring a server-rendered shop, the kind an interviewer asks: what to measure, how the data flows, how to read it, and how to test under load. They are not about Conrad's own setup.
| Page | Covers | Questions |
|---|---|---|
| Metrics, logs and traces | The three kinds of data, the pipeline from pod to dashboard, Loki, Mimir and Tempo, structured logs, distributed tracing, what to alert on | 6 |
| Front-end monitoring | LCP, INP and CLS and how to fix them, real user monitoring versus Lighthouse, sampling and consent, TTFB, tracing from a click to the database | 4 |
| Load testing | k6 and the kinds of load tests, making a test realistic | 1 |
"On the server, every pod exposes metrics on /metrics, request rate, errors, response time percentiles, memory, event loop lag and the cache hit ratio, and writes structured JSON logs to stdout. A collector like Grafana Alloy scrapes and tails them and sends metrics to Mimir, logs to Loki and traces to Tempo, and Grafana shows dashboards and runs the alerts, which are set on symptoms like error rate and p95, not on CPU. In the browser, Grafana Faro measures real users, sampled and only after consent: Core Web Vitals, errors and load timings, and with tracing set up, a click can be followed through the server down to the database. Before big events, k6 load tests show what breaks first."
Nothing yet. Notes filed here show up on every page of this section.
SEO and crawlers
Sitemaps for a catalogue of hundreds of thousands of pages, robots.txt versus noindex, canonicals and crawl budget on a server-rendered shop, and why crawlers must get the same page as users.
Metrics, logs and traces
The three kinds of monitoring data and when to use each, the path from a pod to a Grafana dashboard with Alloy, Loki, Mimir and Tempo, structured logs, Prometheus metric types, exposing metrics from Nitro, percentiles, distributed tracing, and what to alert on.