Power Apps monitoring and Application Insights

How to monitor Power Apps in production — App Monitor, Application Insights integration, and the operational patterns for performance and error tracking.

Updated 2026-10-02

A Power App in production needs operational visibility — is it slow? Are users hitting errors? Where do they spend time? App Monitor provides debugging-focused observation; Application Insights integration provides production-grade telemetry. Together, they're the operational toolkit for serious Power Apps deployments.

App Monitor. Real-time diagnostic tool:

  • Launched from Power Apps Studio while user runs the app.
  • Streams events as they happen.
  • Shows operations: formula evaluations, data calls, errors.
  • Replay-style timeline.

For debugging "why does X happen?" in development. Not for production-wide monitoring.

Application Insights. The Azure Monitor service:

  • Long-term telemetry storage.
  • Rich querying via KQL.
  • Custom dashboards and alerts.
  • Correlation across services.

For production observation, this is the path.

Setup.

  1. Azure subscription with Application Insights instance.
  2. Get the Instrumentation Key (or Connection String).
  3. In Power App, App → Settings → Add Application Insights → enter key.
  4. Save and publish.

Telemetry starts flowing.

What's captured.

  • Page views — screens navigated.
  • Events — explicit Trace() calls.
  • Exceptions — errors raised.
  • Dependencies — connector calls (limited).
  • Performance — operation timing.
  • Custom data — anything you Trace.

Trace() function. Manual instrumentation:

Trace("UserAction", TraceSeverity.Information, {
    action: "Clicked Submit",
    formId: SelectedForm.Id
});

Add Trace() calls at key points in app logic.

Querying telemetry. In Application Insights:

customEvents
| where name == "UserAction"
| where customDimensions.action == "Clicked Submit"
| summarize count() by tostring(customDimensions.formId)

KQL is powerful; learn the basics for effective production debugging.

Custom dashboards.

  • Pin queries to a dashboard.
  • Real-time tile updates.
  • Different audience-specific dashboards (ops vs business).

Alerting.

  • Set thresholds (error rate > 5%, response time > 2s).
  • Alert via email, Teams, ops tools.
  • Action groups for escalation.

Production apps need alerts; without them, issues found by user reports.

What to trace.

  • Screen entry / exit — flow tracking.
  • User actions — buttons clicked, forms submitted.
  • Errors — caught exceptions.
  • External calls — connector results.
  • Performance markers — long operations.

What NOT to trace.

  • Sensitive data — PII, secrets, financial details.
  • Excessive volume — per-keystroke events; signal lost in noise.
  • Internal trivia — info nobody will read.

Performance metrics.

  • App load time — initial render.
  • Screen transition time.
  • Connector response times.
  • Total operation duration.

These align with user-perceived performance; track and optimise.

Error tracking.

  • Caught errors traced explicitly.
  • Uncaught errors auto-captured to App Insights.
  • Stack traces (where available).
  • User session context.

User identification.

  • Anonymous by default.
  • Add user identity to telemetry for debugging specific user issues.
  • Respect privacy — don't trace more than necessary.

Comparison with App Monitor.

| Aspect | App Monitor | App Insights | |---|---|---| | Use | Dev debugging | Production monitoring | | Live data | Yes | Near-real-time | | Historical | No | Yes | | Query | Limited | KQL | | Alerting | No | Yes | | Cost | Free | Azure consumption |

Both have place; use both.

Cost considerations.

  • App Insights priced per GB ingested.
  • High-traffic apps with verbose tracing → meaningful cost.
  • Sampling — record only X% of events to reduce cost.
  • Daily cap — limit max ingestion.

For production apps with > 1000 daily users, budget App Insights cost.

Common pitfalls.

  • No tracing. Production issues invisible.
  • Over-tracing. Cost explodes; signal lost.
  • Sensitive data in traces. Privacy / compliance issue.
  • No alerts. Issues exist; nobody knows.
  • Dashboards unmaintained. Built once, never updated, ignored.
  • Cross-app correlation. Multiple Power Apps with separate App Insights → can't correlate.

Best practices.

  • Standard tracing patterns across apps in the same domain.
  • Centralised App Insights for portfolio observability.
  • Documented KQL queries for common diagnostic scenarios.
  • Runbook integration — alert links to specific queries.
  • Regular review — what's traced, what's needed, what's noise.

Power Automate monitoring.

  • Flow run history is the primary visibility.
  • Can also emit to App Insights from flows (HTTP action).
  • For high-volume flows, App Insights is the long-term store.

Strategic positioning. Production Power Apps without monitoring are operationally opaque. App Insights closes the visibility gap; the discipline of tracing and querying is what unlocks the value. For any app with significant production usage, treat App Insights as standard equipment. The cost is moderate; the operational benefit is substantial. The teams that take production observability seriously have boring incident reviews; the teams that don't have long, painful ones.

Related guides