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.

How is Sentry performance monitoring different from an APM tool like Datadog or New Relic?

Sentry's performance monitoring is tightly integrated with its error tracking, which means you can seamlessly navigate from a slow transaction to the errors that occurred within it. Traditional APM tools offer deeper infrastructure monitoring (server CPU, memory, network) but less integration with error context. Many teams use Sentry for application-level performance and a traditional APM for infrastructure monitoring.

What sample rate should I use for performance monitoring?

For applications handling fewer than 10,000 transactions per day, use 1.0 (100%). For 10,000-100,000 transactions per day, use 0.1-0.5 (10-50%). For more than 100,000 per day, use 0.01-0.1 (1-10%). The goal is enough data for statistical significance at p75 and p95 percentiles. Sentry's dynamic sampling can also automatically adjust rates.

Should PMs care about performance monitoring?

Absolutely. Performance directly impacts the product metrics PMs own: conversion rates, engagement, retention, and user satisfaction. A PM who can look at Sentry and say 'our checkout flow p75 is 3.2 seconds, which is above our 2-second budget' can advocate for performance work with data rather than vibes. Performance budgets should be part of product requirements.

How-To2026-09-1111 min read

How to Set Up Performance Monitoring in Sentry

Performance is a feature. Every 100ms of added latency costs you conversions, engagement, and user satisfaction — but unlike a broken button or a crash, performance degradation is invisible until it is severe. Users do not report that your app feels slow; they just use it less. Performance monitoring makes this invisible problem visible by tracking every transaction, measuring every operation, and alerting you when things slow down.

Sentry, known primarily for error tracking, has evolved into a comprehensive performance monitoring platform. Its transaction-based approach captures the full lifecycle of a request — from the initial HTTP call through database queries, API calls, and rendering — with detailed span breakdowns showing exactly where time is spent. This guide covers setting up Sentry performance monitoring from SDK configuration through building dashboards and alerts that keep your application fast.

Step-by-step guide

Configure the Sentry SDK for performance monitoring

Update your Sentry SDK initialization to enable performance monitoring. Set tracesSampleRate to control what percentage of transactions are captured — start at 0.1 (10%) for high-traffic applications and increase for lower-traffic ones. Enable the BrowserTracing integration for frontend to automatically capture page load and navigation transactions. For the backend, enable the HTTP integration to automatically instrument incoming requests and outgoing API calls.

Update Sentry.init() to include tracesSampleRate (start at 0.1 for production)
Add the BrowserTracing integration for frontend performance monitoring
Enable automatic instrumentation for your backend framework (Express, Fastify, Django, etc.)
Set tracePropagationTargets to include your API domain for distributed tracing

Set up distributed tracing across services

If your application has multiple services (frontend, API, workers), configure distributed tracing so Sentry can link a frontend page load to the API request it triggers and the database queries that API makes. Ensure the sentry-trace and baggage headers are propagated between services. Set tracePropagationTargets in your frontend SDK to include your API domain so trace context is sent with fetch and XHR requests.

Configure tracePropagationTargets to include all your API domains
Verify the sentry-trace header is included in requests between services
Install and configure the Sentry SDK on every service that handles requests
Test distributed tracing by triggering a request and verifying the full trace appears in Sentry

Add custom instrumentation for critical operations

Sentry's automatic instrumentation captures HTTP requests and database queries, but your application likely has critical operations that need custom measurement: cache lookups, queue publish operations, third-party API calls, complex computation, and file processing. Use Sentry's span API to instrument these operations manually. Create a child span for each operation with a descriptive name and op type. This gives you visibility into exactly where time is spent within each transaction.

Identify 5-10 critical operations that are not automatically instrumented
Wrap each operation in a Sentry span with a descriptive op and name
Include relevant data attributes on spans (query complexity, payload size, cache hit/miss)
Verify custom spans appear in the transaction waterfall view in Sentry

Define performance budgets and thresholds

Performance budgets define the acceptable latency for each transaction type. Common budgets: page load under 2 seconds (p75), API responses under 200ms (p75), database queries under 50ms (p75), and background jobs under 30 seconds (p95). Document these budgets in your team's engineering standards and configure them in Sentry. These numbers become the threshold for alerts — anything consistently exceeding the budget triggers investigation.

Define p75 and p95 latency budgets for each major transaction type
Document budgets based on current performance baselines (do not set aspirational targets)
Create a Sentry dashboard widget showing current performance versus budgets
Plan to tighten budgets quarterly as performance improves

Build performance dashboards in Sentry

Create a Sentry dashboard with widgets for: Transaction Duration (p50, p75, p95) over time for your most important transactions, Slowest Transactions (ranked by p75 duration), Throughput (transactions per minute), and Web Vitals (LCP, FID, CLS for frontend). Add a second dashboard for deep dives: Span Duration Breakdown for a specific transaction (showing where time is spent), Database Query Performance, and External API Call Performance. Pin the overview dashboard for weekly team review.

Create an 'Overview' dashboard with top-level performance metrics
Add a 'Transaction Duration' time series widget for your top 5 transactions
Create a 'Deep Dive' dashboard with span-level breakdowns
Add a Web Vitals widget for Core Web Vitals monitoring (LCP, FID, CLS)

Configure performance alerts

Set up Sentry alerts that fire when performance degrades beyond your budgets. Create alerts for: transaction duration p75 exceeding the budget for more than 10 minutes (indicating sustained degradation, not a momentary spike), throughput dropping below the rolling average by more than 50% (indicating a potential outage), and any single transaction taking more than 10 seconds (indicating a hung request). Route performance alerts to a dedicated channel separate from error alerts so they are not lost in noise.

Create a metric alert for p75 transaction duration exceeding your budget
Create a metric alert for throughput drop exceeding 50% of rolling average
Configure alert actions to post to a dedicated performance Slack channel
Set alert resolution notifications so the team knows when performance recovers

Establish a performance review cadence

Performance monitoring without regular review is passive observation. Schedule a weekly 15-minute performance review where the team checks the dashboard, reviews any alerts from the past week, and identifies the top 3 slowest transactions. For each slow transaction, assign investigation to determine whether the slowness is acceptable, fixable, or requires architectural change. Track performance improvements over time to demonstrate the value of monitoring.

Common mistakes

Setting tracesSampleRate too high in production

A tracesSampleRate of 1.0 (100%) sends every transaction to Sentry, which generates massive data volume, increases costs, and can impact application performance. Start at 0.1 (10%) and adjust based on traffic volume. For high-traffic applications, even 0.01 (1%) provides sufficient data for meaningful analysis.

Monitoring only average latency

Average latency hides the worst experiences. A p50 of 100ms and a p99 of 5000ms means half your users have a good experience while 1% wait 50x longer. Always monitor p75 and p95 in addition to (or instead of) averages. The tail latencies reveal the real user experience for your most patient users.

Not correlating performance with deployments

A sudden latency increase that aligns with a deployment is likely caused by that deployment. Configure Sentry releases so performance data is tagged with the deployment version. This makes it trivial to identify which release introduced a regression by comparing performance before and after each deployment.

Tips

Use Sentry's 'Suspect Spans' feature to automatically identify the specific span within a transaction that is causing slowness — this saves hours of manual investigation.

Configure Sentry releases with commit information so you can see exactly which code change introduced a performance regression.

Create a 'Performance Regression' issue template in your tracker that includes the Sentry transaction URL, the affected latency percentile, and the budget threshold it exceeds.

Use Sentry's profiling feature (if available for your platform) to capture CPU profiles alongside transactions for the deepest level of performance insight.

How Vantage helps

Vantage integrates performance awareness into product planning. When generating tickets and requirements, Vantage can surface performance constraints and historical data, ensuring that new features are specified with latency budgets and performance testing requirements from the start.