For current dependency/configuration state, use Health and Doctor. Diagnostics retains aggregate runtime counters; it does not run Health checks or retain their names/results.
The Application-owned App\Diagnostics\Diagnostics collector starts fresh on each Kernel::handle() call. diagnostics() returns that collector after bootstrap. It measures the interval from Kernel handling start until the response is fully produced, before network transmission or browser rendering.
Optional Observability builds bounded parent/child timings and operation metrics on these centralized hooks. It is disabled by default and does not replace the aggregate snapshot below. The opt-in development profiler can activate local capture without activating an external exporter. snapshot()['observability'] reports recorder configuration and safe exporter/consumer failure counts without credentials or exception text; its status is Application-owned, while the ordinary request counters reset per Kernel call. A local completion consumer can inspect one capped execution report independently of external trace sampling.
$requestId = diagnostics()->requestId();
$queryCount = diagnostics()->queryCount();
$elapsedMs = diagnostics()->elapsedMs();
$snapshot = diagnostics()->snapshot();Each request receives a new 32-character lowercase hexadecimal ID generated from 16 cryptographically random bytes. Incoming X-Request-ID is ignored. With diagnostics.response_header enabled (the default), the final response's X-Request-ID contains SqueHub's ID, replacing a controller-supplied value. The same ID is available to the logger for error correlation. Sequential requests through one Application reset route, status, timing, query, cache, and event metrics.
The ID is also available through $request->requestId() and is renewed on every Kernel handling attempt. Enabled API response scopes and explicit ApiError responses always include the trusted X-Request-ID, even when diagnostics.response_header is false. API error bodies use that same ID. This reuses current request correlation; no history of request IDs or error details is added to aggregate diagnostics.
The snapshot contains request_id, method, matched route name and registered pattern, final status, elapsed milliseconds, current and peak allocated PHP memory in bytes, and database totals and per-connection counts/times. Database totals and each connection also include an aggregate slow_queries count; database totals report slow_query_threshold_ms or null when disabled. PHP's peak allocation counter is process-wide and may reflect earlier work in a long-running process. The snapshot returns array values without exposing mutable collector state. Route parameter values and unmatched URL paths are omitted. A 404 therefore has no route field value beyond null.
Database metrics count attempted statements through modern Connection::raw() and QueryBuilder, including failed prepare/execute attempts. They use monotonic timing around PDO preparation and execution. Set diagnostics.slow_query_ms in Config/Diagnostics.php to a finite, non-negative integer or float; an attempt taking at least that many milliseconds increments the total and its connection's slow_queries. null (the default), negative or nonnumeric values, and non-finite values disable the slow counter. The threshold is read at request start and does not log individual statements. Transaction begin, commit, and rollback are not counted. Direct PDO calls, historical migration callbacks receiving PDO, and external database clients are outside this count. diagnostics.database => false disables collection. No database connection is opened merely to collect metrics.
Automatic diagnostics never captures request bodies, query parameter values, cookies, session values or IDs, CSRF tokens, authorization headers, uploaded content, SQL text, or bindings. Diagnostic metadata is operational information, not full request or database tracing. Use application logging deliberately for additional non-sensitive context.
The cache snapshot section reports request-scoped reads, hits, misses, writes, removals, and time_ms for the selected file, array, Redis, or optional Memcached driver. It records no cache keys, values, filenames, or payloads. remember() excludes callback computation from cache timing. These counters reset on every Kernel request; cache use outside an active request still works without accumulating request metrics. See application data cache.
The events section reports emitted, listener_invocations, stopped, failures, and time_ms. Its time includes synchronous listener work. Scheduling an opt-in queued listener does not count as a synchronous listener_invocations call; Queue diagnostics record its dispatch and later worker attempt in their respective process contexts. Counts reset on each Kernel request, while subscriptions remain registered for the Application lifetime. No event class name, listener name, or event payload is captured. See events.
The storage section reports operations, reads, writes, removals, copies, moves, lists, checks, failures, bytes_read, bytes_written, and time_ms. Operation counters measure driver attempts; failures are counted separately. Byte totals cover successful read() and write()/writeStream() calls. Opening a readStream() counts as a read but its later caller-owned consumption is not measured. Metrics reset on each Kernel request. No drive name, logical or physical path, filename, or contents is retained. See Storage.
The auth section reports request-scoped attempts, successes, failures, logins, logouts, and errors. A successful credential attempt counts one attempt, success, and login; manual login counts one login. These counters contain no identity, credential, guard, session ID, or verification time. They reset at the next Kernel request. See authentication.
The separate token_auth section reports attempts, successes, failures, issued, revoked, rotated, pruned, and errors for personal access tokens. It contains no raw token, digest, opaque identifier, identity, guard, ability, name, or Authorization header. A malformed or absent Bearer header can be rejected by the guard before token-manager authentication is attempted; these counters describe actual manager operations rather than every route hit. They reset per Kernel request along with the other aggregate metrics.
The authorization section reports only checks, allowed, denied, and errors. A guest denial counts as a check and deny without invoking a rule. Broken registration or a policy exception counts as a check and error. Each Kernel request resets the counters, while ability and policy registrations remain Application-owned. No identity, subject, ability name, policy name, or decision message is stored. See authorization.
The account_security section reports only password_changes, password_change_failures, reset_tokens_issued, password_resets, verification_tokens_issued, email_verifications, and errors. It retains no guard, identity, address, password, token, or hash. Counters reset per Kernel request; see account security.
The rate_limit section reports checks, allowed, denied, clears, errors, and time_ms. A successful clear counts only when state was removed; a routine 429 is a denial, not an error. Time covers the atomic backend call, excluding named resolver and controller work. All values reset on the next Kernel request. No bucket, named policy, raw key, fingerprint, route, identity, or rule configuration is retained. See rate limiting.
The mail section reports attempts, sent, failures, and time_ms. Each completed send attempt contributes to exactly one success or failure count; transport timing excludes draft construction and validation. These request metrics reset at the next Kernel request. No address, subject, message body, attachment, token, transport name, or credential is retained. The legacy App\Core\Mail path does not contribute to these v2 metrics. See Mail.
The notifications section reports attempts, queued, sent, failures, channel_deliveries, and time_ms. A successfully accepted queued Notification increments attempts and queued in the enqueue context; sent and channel counts update when a worker delivers it. A synchronous send counts its attempt and outcome in one context. Separate processes do not share one snapshot. Timing includes enqueue or channel delivery. No route, recipient, notification class, message, token, or channel payload is retained. Mail deliveries also appear in the separate mail section. See Notifications.
The queue section reports dispatched, processed, retried, failed, errors, worker_starts, worker_stops, timeouts, memory_exits, restart_exits, and time_ms. One accepted public chain() or batch() call counts as one dispatch; internal chain advancement does not count as a second public dispatch. Worker processing remains per settled attempt, and a failing Sync composition item contributes a failure to its terminal status. Time covers dispatch duration; synchronous dispatch includes immediate job execution, while Database and Redis dispatch measure enqueue work. These request-scoped counters reset on each Kernel request; they are not a combined view of separate workers. After-commit dispatch increments dispatched only when the commit callback actually dispatches. No job ID, composition ID, queue name, class name, payload, or exception message is retained. See Queue and Queue composition.
The scheduler section reports evaluated, due, executed, queued, skipped, failed, and time_ms. A due Queue job increments queued after dispatch; duplicate occurrence and overlap denials increment skipped; task and lock failures increment failed. Timing covers the whole tick, including synchronous calls. These request-scoped aggregates contain no task name, job class, payload, callback argument, occurrence key, or exception text. See Scheduler.
The redis section reports operations, reads, writes, failures, and time_ms. A command attempt includes first connection establishment and counts even if the connection fails. Merely resolving redis() or a named connection does not count; an auto infrastructure selection PING counts as a read. Cache, Rate Limit, and Queue operations also update their own aggregate sections, while their Redis commands appear in this lower-layer section. Session has no separate operation counter. The section resets per Kernel request and never stores keys, values, session IDs, limiter fingerprints, prefixes, connection names, hosts, URLs, credentials, or database indexes. See Redis.
The http_client section reports requests, attempts, successful, failed, retried, and time_ms. Requests are logical outbound calls; attempts include redirects and retries. A 4xx/5xx response counts as failed even though it is a completed transport exchange. Time includes configured retry waits. Metrics reset for each incoming Kernel request. No target URL, host, method, query, header, bearer token, Basic credential, request or response body, multipart filename, or sink path is retained. See HTTP Client.
The webhooks section reports outgoing_events, delivery_attempts, delivery_successes, delivery_failures, delivery_retries, incoming_verified, incoming_rejected, and incoming_duplicates. These are request-scoped aggregate counters. A separately running Queue worker has its own process context; its delivery counters do not retroactively appear in the enqueue request's snapshot. No peer name, URL, event type or ID, delivery ID, signature, secret, body, or remote response content is retained. See Webhooks.
The optional local Agent/MCP process does not add an agent section to the HTTP request snapshot for Agent and AI integration. It does not retain prompts, tool arguments, documentation excerpts, plan content, or resource results in Diagnostics. Any later Agent metrics must remain aggregate and privacy-safe rather than treating MCP traffic as an ordinary browser request.
Application-facing Plugins import
This guide covers a subsystem or maintenance workflow; see Plugins for supported application imports. Canonical framework namespaces remain supported.
Cryptography
snapshot()['crypt'] reports only encryptions, decryptions, signatures, verifications, failures, and time_ms. Invalid signatures returning false count as verifications; exceptional failures increment failures. No key, key ID, purpose, plaintext, ciphertext, MAC, token, nonce, or tag is retained. See Cryptography.