Monitoring modes

Lookout separates error monitoring (exceptions and rich context on POST /api/ingest) from performance monitoring (server spans on POST /api/ingest/trace and optional browser RUM on POST /api/ingest/rum), and log ingest (POST /api/ingest/log) for application and infrastructure log lines. You can mix modes; project settings are the server-side gates for traces/RUM, logs, metrics, and end-user feedback separately.

Error monitoring

• Primary endpoint: POST https://lookout.dply.io/api/ingest (aliases in the protocol overview).
• Counts toward your organization’s error-event quota where applicable; includes stack traces, breadcrumbs, user/context, trace correlation fields, and optional client grouping hints (fingerprint, grouping_override).
• Cannot be disabled per project via the UI: if you have the API key, you can send errors. Use org/process controls (allowlists, env separation) if you need hard isolation.

Bottleneck hints (traces)

The app derives execution insights from stored spans—slowest operations, coarse “lanes” (database, HTTP, cache, queue, app), and optional overlap hints—similar to what continuous profilers surface at a glance (e.g. Blackfire’s monitoring + profiling story). Lookout is not a line-by-line deterministic profiler: use Project → Profiles for uploaded CPU/flame data (POST /api/ingest/profile) and open traces for the waterfall.

Error + performance monitoring

Spans are ingested on POST https://lookout.dply.io/api/ingest/trace; optional Web Vitals and SPA navigation beacons use POST https://lookout.dply.io/api/ingest/rum (see Ingest API — RUM). They do not count toward the monthly error quota but still require a valid project API key and are blocked when billing is delinquent.

Project setting: in Project settings → Monitoring modes, Accept performance trace ingest must stay enabled. When it is off, trace and RUM requests return 403 with a short JSON message so misconfigured SDKs fail loudly instead of silently dropping data you did not intend to collect.

Log ingest uses a separate checkbox (Accept log ingest). When it is off, POST /api/ingest/log returns 403; errors and traces are unaffected.

User feedback (POST /api/ingest/feedback) is gated by Accept user feedback ingest. When it is off, that endpoint returns 403; error ingest is unchanged.

On the app side, enable your SDK’s performance options only when this project accepts traces—for example the Laravel lookout/tracing package uses LOOKOUT_PERFORMANCE_ENABLED and related config; see the Ingest API — Distributed tracing section.

Canonical error payload (contract)

The authoritative field list and types for error ingest live in the Ingest API reference. Lookout also accepts a camelCase variant of several fields for compatibility with common PHP and browser clients; those are normalized before validation. Native snake_case keys win when both are present.

Notable normalized keys include exceptionClass, stacktrace, isLog → is_log, openFrameIndex → open_frame_index, overriddenGrouping → grouping_override (used as custom fingerprint when fingerprint is empty), and attributes merged into context.

REST API

Project listings and detail include performance_ingest_enabled, log_ingest_enabled, metrics_ingest_enabled, and user_feedback_ingest_enabled so automation can align SDK config with the server gate. See REST API (v1).