urgentry

The migration automatically sends raw error events via the DSN swap, but it does not automatically copy alert rules. You must export your current Sentry alert rules via the API or UI and manually recreate them in urgentry. The chunks do not mention whether Sentry dashboards are copied or if they must be rebuilt.

Add explicit documentation on whether Sentry dashboards, Discover queries, or custom dashboard configurations transfer to urgentry or must be rebuilt.

Where we looked: /guides/evaluate/sentry-compatibility-checklist, /guides/evaluate/sentry-compatibility-checklist, /guides/evaluate/exporting-sentry-history-before-cutover, /migration-from-sentry, /docs/faq

The chunks do not state a specific maximum event payload size for the urgentry API/backend itself. They indicate that a 413 is returned by the reverse proxy, not the urgentry backend: nginx defaults `client_max_body_size` to 1 MB, and urgentry recommends raising this proxy limit to 20 MB. Chunk [10] notes that urgentry advertises either a 200 KB or 1 MB event ceiling, but it does not state that the API returns a 413 at that threshold.

Document the specific maximum event payload size (in MB) that the urgentry ingest API itself enforces before returning a 413, distinct from reverse proxy defaults.

Where we looked: /guides/self-hosting/silent-200-ok-failures, /guides/self-hosting/kubernetes-helm-ha, /guides/evaluate/events-not-showing-up, /guides/evaluate/validating-event-content-after-dsn-swap, /guides/self-hosting/silent-200-ok-failures

The retrieved chunks do not specifically address SIGTERM signal handling. However, across multiple SDKs the documentation indicates that you must manually call a flush or shutdown method during graceful shutdown or process exit rather than relying on automatic behavior: the Go SDK requires `sentry.Flush` during graceful shutdown ([4]); the .NET SDK states that flushing inside the stopping callback is not optional when the host shuts down ([7]); Node.js examples show manual `Sentry.flush` before `process.exit` ([3]); Flutter background isolates must call `Sentry.close()` before destruction ([9]); and the Next.js edge runtime requires explicit flushing unless using the provided wrapper ([10]). Automatic flush on normal process exit is mentioned only for the Rust SDK (when the guard drops) ([6]) and for PHP under FPM ([16]). No chunk describes a built-in SIGTERM handler that drains the queue automatically.

Add explicit documentation about Unix signal handling (SIGTERM, SIGINT) and whether the SDK registers signal handlers to flush automatically, or if users must trap signals and call flush/close manually.

Where we looked: /guides/errors/go-error-tracking, /guides/errors/dotnet-error-monitoring, /guides/errors/nodejs-error-tracking, /guides/errors/mobile-error-tracking, /guides/errors/nextjs-error-monitoring, /guides/errors/rust-error-monitoring, /guides/errors/laravel-php-error-tracking

Urgentry does not publish a p99 ingestion latency for a 10,000 events per second benchmark. The only published p99 ingest latency figure is "under 40 ms end-to-end on the Tiny lane benchmark" at 400 events per second on a 1-vCPU/1 GB VPS. The site notes that "bigger hardware lanes (Postgres, multi-core VPS, larger RAM) run higher throughput," but states that "exact numbers from that test will appear in the benchmark documentation as the measurement set grows." No benchmark results for 10,000 events per second are provided.

Publish benchmark results for higher-throughput configurations, including p99 latency at 10,000 events per second, or document the expected hardware requirements and scaling behavior for that load.

Where we looked: /guides/evaluate/reading-benchmarks, /guides/evaluate/reading-benchmarks

The Tiny lane — a single-vCPU, 1 GB RAM VPS, which is the smallest reproducible configuration — sustained 400 events per second (24,000 events per minute) over 30 minutes without falling behind. At 500 events per second (30,000 per minute) the system continues to accept events, but SQLite write latency increases noticeably. The benchmark documentation explicitly states it does not characterize backlog or drop behavior, so the exact ingest rate at which the Tiny deployment begins dropping events is not published.

Publish the observed drop threshold or maximum burst capacity before queue saturation for the Tiny lane, or explicitly state the highest tested rate before events are dropped.

Where we looked: /guides/evaluate/reading-benchmarks, /guides/evaluate/reading-benchmarks