RUM vanishes after a CSP change while a browser monitor fails at MFA
An e-commerce team deploys a React single-page app that calls APIs on api.example.com. The Elastic RUM agent is configured with serviceName storefront-rum and serverUrl https://apm.example.com. After a security hardening release, RUM transaction data disappears, but the APM Server still receives data from backend Java services. Browser devtools show a Content-Security-Policy violation for connect-src, and the APM Server sits behind an Nginx proxy that strips headers not on an allowlist; the RUM agent's requests return 403. Separately, a Synthetics browser monitor that logs in with a shared test account has failed for three days at the password step, while the lightweight TCP monitor on the same URL reports up. The test account was migrated to an identity provider that now requires an OTP sent by email. The team wants synthetic coverage of the full checkout journey and cannot disable MFA for all users, but can create a dedicated test identity.
1. Diagnose the RUM loss across the browser, proxy and APM Server layers, and give the specific configuration changes.
Read the worked answer
RUM is a browser intake path, so it must pass three gates: the page CSP, CORS preflight, and the APM Server RUM endpoint. The CSP violation for connect-src blocks the agent from calling https://apm.example.com before any request leaves the browser. Add the APM Server origin to connect-src, and keep the API origin there as well.
CORS is the second gate. The proxy must forward Origin, Content-Type, Accept and the preflight headers, and must not answer OPTIONS itself with a 403. APM Server must have RUM enabled and the storefront origin in its allowed origins list; a 403 in the browser usually means the proxy rejected the request or the APM Server refused the origin. Check the APM Server log for CORS or origin errors rather than guessing.
Confirm serverUrl is the base URL the agent expects, with the agent appending the RUM intake path. After the fixes, verify with a hard reload and a network trace showing a successful intake response, then confirm documents in the RUM data stream. Backend APM working does not prove RUM works, because they use different endpoints and authentication assumptions.
2. Why does the TCP monitor report up while the browser monitor fails, and how would you restore reliable synthetic coverage of checkout with MFA in place?
Read the worked answer
The TCP monitor only proves that a socket and TLS handshake succeed on the URL's host and port. It never loads the app or authenticates, so an identity-provider change that breaks login is invisible to it. The browser monitor drives a real browser and fails at the password step, which points to either a changed selector or the new OTP challenge.
The fix is a dedicated synthetic identity, not a global MFA exemption. Create a service account for Synthetics, scope an identity-provider policy to that account so it can authenticate without email OTP, and restrict the policy by the egress IP of the private location if possible. Store the credential as a secure parameter rather than in the journey source. If policy cannot exempt the account, use a TOTP seed and generate the code inside the journey; email OTP is unsuitable for automation because it depends on an external mailbox.
Assert on business outcomes, not only page load: cart contents, order confirmation and the API response. Keep the TCP monitor as a cheap availability signal, but alert on the browser journey separately so a login outage is not masked.
3. Which synthetic signals would you alert on to distinguish a broken login from a slow payment step, and what data supports each alert?
Read the worked answer
Synthetics browser journeys produce summary and step-level documents in the synthetics data streams. Those carry journey and step names, status and duration, plus monitor and location identifiers. Use them as two separate alert classes.
For availability, alert when a journey run contains a failed step, grouped by journey and location, and require two consecutive failures to reduce flakiness. That fires on a broken login or a changed selector. For performance, alert on the duration of the payment step, not the whole journey, because total journey duration hides which step regressed. A threshold such as payment step above 15 seconds for three consecutive runs is actionable; a total-journey threshold is not.
Include the failing step name and the monitor ID in the alert body so on-call knows whether to look at the identity provider or the payment API. Keep the uptime or TCP monitor as a separate low-level signal, and do not let its green state suppress the browser journey alert. Review the journey after any auth or checkout change.