App performance monitoring
Measure what your users wait for (web vitals, app start, screens and every API call) and see each slow call next to the server's time for the same request.
Turn on sov.perf and the SDK measures in the app: web vitals in browsers, app start and screens on iOS, Android and Flutter, every network call the SDK makes, and your own traces. Each network measurement carries the W3C traceparent the SDK sent with that request, so the console puts the app's time next to the gateway's time for the same route, and a slow call opens the server-side trace of that very request. That join is something Firebase Performance Monitoring doesn't give you.
sov.perf.install({ release: '2.4.1', sampleRate: 0.5 }) // half of page loads
// LCP, INP, CLS, FCP and TTFB per page, and every Sovaria request, automatically.
await sov.perf.trace('checkout', () => pay(cart)) // your own step#What is measured
| Kind | Name | Where |
|---|---|---|
| Web vital | LCP, INP, CLS, FCP, TTFB (rated good / needs improvement / poor at p75, web.dev thresholds) | Browsers, once per page load, per page route (ids collapsed: /orders/:id) |
| Network | GET /rest/v1/orders (method + route with ids collapsed) | Every SDK, every request the SDK makes; status and trace id kept |
| App start | cold | iOS, Android, Flutter |
| Screen | The name you give | iOS (incl. a SwiftUI modifier), Android, Flutter |
| Trace | The name you give | Every SDK: trace(name, fn) or start(name) → end() |
#In the console
- Observability › App performance: web vitals tiles (p75 and the share of good / poor page loads), a p75 line over time and a table per page.
- Network vs server: each route's p50 / p95 measured in the app beside the gateway's p50 / p95 for the same route. A big gap is network or device; slow on both sides is the server (then see Query Performance or the function).
- App start and screens for mobile apps, and Slow requests: the slowest calls, each opening a drawer with the app's spans and the server's hops (servers keep hop-by-hop traces for refused and failed requests).
- Percentiles come from hourly histograms (log-scale buckets, within about 7 %), so they stay fast for millions of measurements; raw measurements are kept for drill-down for the plan's days.
#Plans and limits
| Free | Pro | Ultra | Team | Enterprise | |
|---|---|---|---|---|---|
| App performance measurements per month (per project) | 50,000 | 1,000,000 | 5,000,000 | 20,000,000 | 100,000,000 |
| Days app performance measurements are kept | 7 days | 30 days | 90 days | 90 days | 365 days |
Measurements are batched (every 10 s, up to 100 per request) and count against the month; past the limit they are dropped and counted. Use sampleRate to send a share of sessions.
#Coming from Firebase or Supabase?
| Platform | What this is called there |
|---|---|
| Firebase | Firebase Performance Monitoring |
| Sovaria | App performance monitoring |
Moving an existing app? Migrate from Supabase or Firebase imports users (with their passwords), data, files and rules.