How is Vantage different from ChatGPT or Claude?

ChatGPT and Claude are great for one-off generation. Vantage is a full workspace. It connects your tools, tracks dependencies across projects, catches conflicts between products, and surfaces what needs your attention every morning. It also remembers every past decision, so a new PM can query across all projects and get cited answers in seconds.

Do I have to switch away from Notion or Linear?

No. You keep all your tools. Vantage connects to them and builds intelligence on top. When you're ready, you can push tickets to Linear or Jira. But the value starts before you create anything — just by connecting your tools and seeing what the intelligence layer surfaces.

What happens on day one?

You connect your tools — GitHub, Linear, Slack — 2 minutes each. Vantage indexes your existing data overnight. By the next morning, you see your first decision queue: what's stale, what conflicts, what changed. No manual setup. No templates to fill out.

What if I only manage one project?

Vantage works for single projects, but it shines when you manage 3–5 or more. Conflict detection, cross-project memory, and the decision queue are most valuable when you have multiple projects that need to stay in sync. If you manage one project, start with the free tier and see if the cited query engine alone saves you time.

All data encrypted in transit and at rest. We never train on your data — the AI providers we use are contractually barred from it. You can disconnect any integration or delete your account at any time. Pursuing SOC 2 Type II.

How does Vantage keep documents and tickets up to date?

When context shifts, you add the new information and Vantage rebuilds every connected deliverable. Documents, prototypes, and tickets all update. You review the changes, accept or reject each one, and approve. Nothing updates silently, and every change is traceable.

How do I get started?

Sign up free at app.vantageos.tech. Connect your tools, and generate your first grounded document within minutes. No credit card required. Upgrade when you need more projects or features.

What is Real User Monitoring (RUM)?

Real User Monitoring collects performance metrics from actual user browsers as they interact with your website or application. Unlike synthetic monitoring (which runs automated tests from controlled environments), RUM captures real-world performance across the full diversity of user devices, networks, locations, and browsers. It measures metrics like page load time, Core Web Vitals, and custom interaction timings from real user sessions.

What are Core Web Vitals and why do they matter?

Core Web Vitals are three metrics that Google uses to measure user experience: Largest Contentful Paint (LCP, loading speed — target under 2.5s), First Input Delay (FID, interactivity — target under 100ms), and Cumulative Layout Shift (CLS, visual stability — target under 0.1). They matter because Google uses them as ranking signals for search results, and they directly correlate with user satisfaction, conversion rates, and bounce rates.

How much does Sentry RUM cost?

Sentry's pricing for performance monitoring is based on the number of transactions (page loads and custom measurements) you capture per month. The free tier includes 100K transactions. Paid plans start at the Team tier. Control costs by adjusting tracesSampleRate — a 10% sample rate (0.1) on a site with 1M monthly page views captures 100K transactions, fitting within the free tier. Increase sampling gradually as you need more statistical confidence.

How-To2026-09-0810 min read

How to Set Up Real User Monitoring in Sentry

Synthetic performance tests tell you how your application performs in ideal conditions. Real User Monitoring tells you how it performs for actual users — on slow networks, underpowered devices, and in unpredictable real-world conditions. The gap between synthetic and real-world performance is often shockingly large, and RUM closes that gap by measuring what users actually experience.

Sentry is primarily known for error tracking, but its performance monitoring and RUM capabilities provide a unified view of both errors and performance in one platform. This guide shows you how to configure Sentry's RUM to track Core Web Vitals, identify slow pages, and correlate performance issues with user experience degradation.

Step-by-step guide

Install and Initialize the Sentry Browser SDK

Install the Sentry SDK for your frontend framework: '@sentry/react' for React, '@sentry/vue' for Vue, or '@sentry/browser' for vanilla JavaScript. Initialize Sentry at the earliest possible point in your application — before any other JavaScript runs. Set 'tracesSampleRate' to control what percentage of transactions are captured (start with 0.1 for 10% in production to balance data quality with cost). Enable the BrowserTracing integration which automatically instruments page loads and navigation.

Set 'tracesSampleRate' to 1.0 in development and 0.1-0.2 in production — adjust based on traffic volume
Configure 'tracePropagationTargets' to include your API domain so frontend transactions connect to backend spans
Set 'environment' and 'release' tags so you can filter performance data by deployment

Enable Core Web Vitals Collection

Sentry automatically captures Core Web Vitals (LCP, FID, CLS) when the BrowserTracing integration is enabled. Verify that these metrics appear in your Sentry dashboard under Performance > Web Vitals. LCP (Largest Contentful Paint) measures loading speed, FID (First Input Delay) measures interactivity, and CLS (Cumulative Layout Shift) measures visual stability. These are the same metrics Google uses for search ranking, so they matter for both UX and SEO.

Check that your LCP, FID, and CLS scores appear in Sentry's Web Vitals overview within 24 hours of deployment
Set up alerts for when Web Vitals degrade below 'Good' thresholds: LCP > 2.5s, FID > 100ms, CLS > 0.1

Configure Custom Performance Instrumentation

While auto-instrumentation covers page loads and API calls, you should manually instrument critical user interactions that Sentry can't detect automatically. Use 'Sentry.startTransaction' to measure key workflows: time from clicking 'Generate Report' to seeing results, time from submitting a form to receiving confirmation, or time from opening a modal to its content loading. These custom measurements capture the performance that matters most to your users.

Wrap critical user flows in custom transactions with descriptive names like 'user.generate_report' or 'checkout.process_payment'
Add custom spans within transactions to measure sub-steps — this helps pinpoint which part of a workflow is slow

Set Up Performance Alerts

Configure Sentry alerts that fire when performance degrades. Create alerts for: average page load time exceeding your target (e.g., > 3 seconds), LCP exceeding the 'Poor' threshold (> 4 seconds), and when a specific transaction's p95 latency spikes above baseline. Use percentage-based thresholds rather than absolute values when possible — 'LCP is 50% worse than last week' catches regressions regardless of your baseline.

Create separate alerts for different page types — your landing page has different performance expectations than your dashboard
Set alert conditions to require sustained degradation (e.g., 'for at least 10 minutes') to avoid alerting on transient spikes

Build a RUM Dashboard

Create a Sentry dashboard with key RUM widgets: Web Vitals summary (LCP, FID, CLS with good/needs-improvement/poor distribution), slowest pages by transaction name, performance over time trend, and a geographic breakdown showing performance by user location. This dashboard should be the first place your team looks when investigating performance complaints or planning optimization work.

Add a 'Performance by Browser' widget to identify browser-specific performance issues
Include an 'Apdex Score' widget that shows the percentage of user sessions with satisfactory performance
Add a 'Slowest Transactions' table sorted by p75 duration to identify the worst-performing pages

Correlate Performance with Errors and Releases

Sentry's unique advantage is correlating performance data with error data and release information. Use the Releases view to see whether a new deployment degraded performance. Use the Discover view to query for transactions that also had errors — slow-and-broken experiences are worse than just slow ones. This correlation helps you prioritize: a page that's slow AND error-prone gets fixed before a page that's just slow.

Tag releases with commit hashes so you can trace performance regressions to specific code changes
Use Sentry's 'Suspect Commits' feature to automatically identify which commit likely caused a performance regression

Common mistakes

Setting tracesSampleRate Too High in Production

A sample rate of 1.0 (100%) in production captures every transaction, which can be expensive for high-traffic sites and may impact client-side performance. Start with 0.1 (10%) and increase only if you need more data. For most products, 10-20% sampling provides statistically reliable metrics without excessive cost.

Only Monitoring Page Loads, Not User Interactions

Page load performance is important but it's only half the story. Users spend most of their time interacting with already-loaded pages — clicking buttons, submitting forms, navigating between views. Add custom instrumentation for these interactions to get a complete picture of user-perceived performance.

Ignoring Performance by Segment

Your average p50 page load time might look great, but users in Southeast Asia on mobile networks might experience 8-second loads. Break down RUM data by geography, device type, connection speed, and browser to find the segments where performance is worst. These are often your biggest improvement opportunities.

Not Connecting Frontend Performance to Backend Tracing

A slow page load might be caused by a slow API call, which is caused by a slow database query. Without distributed tracing connecting frontend transactions to backend spans, you can only see that the page is slow, not why. Configure trace propagation headers so Sentry links the full request chain.

Tips

Use Sentry's Session Replay feature alongside RUM to watch actual user sessions where performance was poor — seeing the user's experience makes performance issues visceral and easier to prioritize.

Set up a performance budget: define target thresholds for LCP, FID, and CLS, and create Sentry alerts that fire when any metric exceeds its budget.

Compare RUM data with your Lighthouse CI scores — differences between synthetic and real-world performance reveal issues that lab tests can't catch.

Use Sentry's 'Trends' view to automatically detect transactions whose performance is trending worse over time, catching slow regressions before they become critical.

How Vantage helps

Vantage helps product teams include performance requirements in their specifications. When writing PRDs for user-facing features, Vantage ensures that performance budgets, monitoring setup, and alerting thresholds are captured as non-functional requirements so engineering teams ship with observability built in from the start.