Know why it’s slow, not just that it is.
One place for your backend services, web apps and mobile apps: APM, real-user monitoring, logs, alerts and load tests. When something breaks, TaskTrooper follows the request from the user’s screen to the database and names the cause.
Included with Team and Enterprise, nothing to deploy. On the free Solo edition you run TaskTrooper Telemetry yourself, or connect New Relic or a similar tool.
Root causeHigh confidence · found 7 min after the deploy
- Users feel itshop-web homepage LCP 1.6 s → 4.8 s
- Along the path
storefront-bff → recommendation-api → reco-db - Becausereco-db queries 63× slower since migration 0042
- Suggested fix0042 dropped the index on
recommendations(user_id). Recreate it, or roll back 0042.
Synthetic example: a fictional shop, not customer data.
Today it takes hours and a war room. Here it takes minutes.
Without the dependency and the deploy next to the alert, teams hear it from customers and search by hand. TaskTrooper Telemetry alerts on what users feel, and the incident arrives with the dependency, the deploy and the evidence that point to the cause, or it says “unknown” when the evidence is thin.
Deploy
reco-db migration 0042 ships with recommendation-api 2.14.
Customers notice
Support tickets say the homepage hangs. No alert fired: CPU and error rate look normal.
War room
On-call is paged. Five people join a call, each in a different dashboard.
Guessing
Logs are grepped service by service. recommendation-api is restarted twice; nothing changes.
Found
Someone spots the migration and rolls it back, almost four hours after the deploy.
Deploy
The same migration ships with recommendation-api 2.14.
Latency rises
Homepage p95 climbs from 380 ms to 4.1 s for real users.
Alert with the cause
The team's Slack channel gets the KPI alert, and it names reco-db: queries 63× slower since migration 0042.
Developer reverts
The developer who shipped 0042 sees the alert in the channel and reverts it. No war room.
Resolved
p95 is back to 380 ms and the incident closes itself.
Synthetic example: a fictional shop, not customer data.
Backend, web and mobile, read as one system.
Add one SDK per service or app. A tap in the mobile app or a click on the website joins the backend trace it caused, so a slow screen and the slow query behind it are one investigation, not three tools.
Backend
HTTP services, workers and queue consumers
- Throughput, errors and p50/p95/p99 per route
- Traces across services, databases and caches
- Consumer lag, retries and dead letters
- Continuous profiling and flame graphs
Go · Java and Kotlin · .NET · Python · Node.js
Web
Single-page apps and websites
- Page views, visitors and sessions
- Web Vitals: LCP, INP, CLS, TTFB
- JS errors with source maps
- Network calls joined to backend traces, session replay
Browser · React · Vue · Angular
Mobile
iOS, Android and cross-platform apps
- Screens, sessions, cold and warm start
- Crashes (native included) with symbolication
- Slow frames and API calls joined to backend traces
- Session replay
iOS · Android · React Native · Flutter
Signals across all three
- APM
- Every endpoint and queue consumer with throughput, error rate and p50, p95, p99. Traces show the full call tree; consumers show lag, retries and dead letters.
- Real-user monitoring
- Page and screen views, Web Vitals and app start, JS errors and crashes, network calls and session replay, for web, iOS, Android, React Native and Flutter.
- Logs and alerting
- Log search linked to traces. KPIs with error-budget burn-rate alerts, plus metric, log-pattern and anomaly monitors, delivered to Slack with the cause attached.
- Load testing
- Generate a scenario from real production traffic, run it against a verified staging host, and read the results next to the same telemetry.
Also in the box: continuous profiling with flame graphs, host and Kubernetes metrics, serverless functions, and LLM calls with token cost.
Connect a project. Get the alerts you would have written after the outage.
TaskTrooper Telemetry reads your routes, consumers and jobs, matches them with production traffic, and proposes a KPI and its monitors for each critical path. You accept, edit or dismiss.
r := chi.NewRouter()r.Post("/orders", h.CreateOrder)r.Get("/orders/{id}", h.GetOrder)r.Get("/healthz", h.Health)consumer.Handle("payments.settled", h.Settle)
POST /orders
KPI 99.5% availability over 30 days
Critical path
GET /orders/:id
p95 latency under 300 ms
Highest traffic
payments.settled
Consumer lag under 1,000 messages
Queue consumer
Synthetic example.
Ask your coding agent, with evidence.
An MCP server gives your coding agent the same services, traces, logs, incidents and deploys you see. Agent skills tell it how to investigate and how to set up alerts and SLOs from your own traffic, with your approval for every change. One command installs both in Claude Code, Muse Code, Cursor, Antigravity, Codex CLI, OpenCode or Gemini CLI.
Install guide, MCP server and skills- trooper-diagnose
- Something is slow, failing or alerting. Walks incidents, KPIs, endpoint root cause, traces, logs and deploys, cites every claim and says “unknown” when the evidence is thin.
- trooper-alerts
- Set up alerting for a project: reads services, traffic and existing rules, derives every threshold from your data, previews how often each would have fired, and creates the approved list.
- trooper-query
- A question about production data: slowest endpoints, error logs for a trace, what deployed today.
Connect your first service.
Install an SDK, set a DSN and deploy. Your service shows up with its first request.