Product Changelog

The Server Monitoring page now displays the last hour metrics for all servers for a quick overview of their status

DeadBro's server monitor previously only paged you when CPU, memory, or disk crossed a threshold — a server that simply stopped sending heartbeats (crashed agent, network partition, box on fire) produced no alert at all. We've closed that gap:

- Escalating dead man's switch — if a server goes quiet, you now get paged at 3.5 minutes (normal priority), 10 minutes (high priority), and 30 minutes (emergency, bypasses quiet hours) — plus a recovery notification once it checks back in, with how long it was down.

- Separate opt-in — heartbeat alerts have their own Pushover toggle on your profile, independent of site up/down notifications, since they fire much more readily than a full outage.

- Pause per server — decommissioning or intentionally shutting down a box? Pause heartbeat alerts for it from the server settings so it stops paging you.

The performance page now includes a time breakdown of your traffic. See at a glance how many requests you get per hour, per day, and beyond — making it easy to spot peaks, quiet periods, and longer-term trends.

Open the performance page of any application to check it out.

A request can grow process memory by hundreds of megabytes while loading only a few thousand database records — and until now there was no way to explain it. The Memory panel on every request now answers that. It tells you whether the growth was transient (objects allocated and immediately reclaimed — RSS held by allocator fragmentation, not a leak) or retained (objects still live at the end of the request — the real leak signal), reports off-heap memory malloc'd outside the Ruby object heap (large strings and parsed response bodies), and breaks down allocations by phase in a single bar — how many objects came from SQL, view rendering, Elasticsearch, and your own application code. When deeper allocation tracking is enabled, a new Allocation sources table points at the exact file:line that created the memory — the gold-standard "this line allocated 300 MB" answer. Requires dead_bro 0.2.25.

Every panel also now explains itself in plain language. New "What this means" call-outs read the numbers for you and turn them into a sentence — "ActiveRecord models were only 1% of allocations; the 414 MB of growth is dominated by transient strings, typically response deserialization, so reducing model loads won't help" — and similar guidance now appears inline next to the data it describes across the whole request page: a slow Elasticsearch query, a partial rendered hundreds of times, a Redis command storm, a sequential scan, or a duplicate query each get an actionable note right where you are looking, instead of buried in one block at the top.

Every request detail page now shows a Request Trace — a horizontal waterfall chart that places every instrumented event on a shared time axis so you can see exactly what was happening and when during a request. Each span type gets its own colour: SQL queries in purple, outbound HTTP calls in amber, cache operations in green, Redis commands in blue, Elasticsearch in cyan, and view rendering in orange. Parallel operations show side-by-side so you can instantly see whether a slow Stripe API call is blocking your response or running concurrently with SQL. N+1 query groups are outlined in orange. Hover any bar for the label and exact duration; click Show all spans to expand beyond the initial preview. Requires dead_bro 0.2.21.

The Performance tab on every request type page now opens with a combined one-hour chart above the breakdown table. The chart plots requests per minute as vertical bars alongside P50 and P99 response times as overlaid lines, so you can see throughput and latency trends together for that endpoint over the last hour. Each minute bucket is individually labelled so spikes are easy to pin to a specific time.

New requests now appear automatically on the Timeline and Issues pages—not just request-type views—without any manual refresh. Incoming rows are briefly highlighted so you can spot what just arrived. The polling pauses automatically when the tab is in the background and resumes when you return, so it only does work when you are actually looking at the page.

The system monitor dashboard has been significantly expanded. Process Memory and Process Threads charts now render one series per worker process, so you can see how individual Puma workers or Sidekiq processes diverge from each other over time. A Process dropdown lets you focus any chart on a single process when you need to isolate one. Two new charts join the dashboard: Disk Usage (percentage of each mount used over time) and Network I/O (bytes sent and received per second). The Queue Activity and Individual Queue Sizes charts have been converted to a true datetime axis so they align correctly with the rest of the page. At the bottom, a new Process Status table shows the latest snapshot for each worker: boot time, uptime, and a full GC breakdown — major and minor cycle counts, heap free and live slots, and total allocated objects — so you can spot long-running or GC-heavy workers at a glance. Available on Enterprise.

Every frame in an error backtrace is now a clickable link that opens the exact file and line in your repository. Paste your GitHub, GitLab, or Bitbucket repo URL into Application Settings and DeadBro does the rest—no OAuth, no API token, no deploy webhook required. Links are generated locally using the git commit SHA that was already in your payload, so they point to exactly the code that was running when the error occurred. Non-production environments automatically inherit the production repo URL, so staging and review apps get working links without any extra configuration. Links also appear on SQL query backtraces, so you can jump straight to the code that issued a slow or repeated query.

You can now share any request detail page with a single click. Hit Share on any request, copy the generated link, and send it to anyone — no login required. The link expires in 30 minutes and renders a read-only view of the full request: breakdown, timeline, SQL queries, logs, and error details, without exposing account controls or sensitive settings. Available on Growth plans and above.

You can now report handled exceptions to DeadBro from any rescue block — without re-raising. Call DeadBro.track(e) and the error is captured with its class, message, backtrace, and the log lines that ran up to that point. Pass any keyword arguments you want to see alongside it — DeadBro.track(e, user_id: current_user.id, order: order.id) — and they appear as a context block in the error detail view. This complements automatic unhandled exception tracking: DeadBro now sees every error your app is aware of, not just the ones that crash a request. Requires dead_bro 0.2.17.

DeadBro now tracks how many ActiveRecord model instances are hydrated during each web request and background job. The count appears as AR Objects in the Counts panel of every request detail page. When a request instantiates 10 000 or more objects it is automatically flagged as a standout and surfaces in the Issues page with a teal AR Nk badge showing the rounded count—a quick signal that something is loading far more data than it needs to. The instrumentation hooks into Rails' native instantiation.active_record notification so there is nothing to configure and the overhead is negligible. Requires dead_bro 0.2.15.

The All Requests, Slow Requests, and Timeline tables have also been refreshed. Every row now shows a Mem column with the process RSS at the time of the request (orange above 200 MB, red above 500 MB), and the old single N+1 badge has been replaced with a compact Flags column that surfaces all active issues at once—N+1, Slow, Mem, SQL+, and AR—so you can triage a list of requests without opening each one.

The performance breakdown bar now tracks two more slices of time that were previously invisible. DB Wait shows how long your threads spend blocked waiting to acquire a database connection from the pool—a separate cost from query execution that can quietly inflate response times when the pool is undersized. Queue time (already shown for web requests) is now also reported for background jobs, measured from when the job was enqueued to when a worker actually picked it up. Both metrics are collected by dead_bro 0.2.14 and require no configuration changes.

The gem now instruments Redis at the client level, capturing every command, pipeline, and MULTI/EXEC block executed during a request or job—with command name, key, duration, and database index. Redis time will appear alongside SQL, cache, and view rendering in the existing performance breakdown so you can see exactly how much of your response time Redis is responsible for. Requires dead_bro 0.2.14.

Every request detail page now shows a Concurrent Requests panel — a Gantt-style chart of every other request that was running on your application at the same time. The current request is pinned at the top as a blue anchor bar; the rest are sorted by start time and colour-coded by status (green for 2xx, amber for 4xx, red for 5xx with a glow). The shared time axis shows the exact window from the earliest start to the latest end, so you can see pile-ups, long-running stragglers, and overlapping errors at a glance. Click any row to jump straight into that request’s detail page.

Each application now has a Timeline page in the sidebar that lists every web request in chronological order—newest first—so you can scan what happened across your app instead of drilling into one endpoint at a time. Pick a start and end date to focus on a specific window (an incident, a deploy, a spike), filter by duration or path (wildcards supported), and scroll through the full list with infinite loading. Open any row to jump straight into request detail.

Each request type now opens on a Performance tab. A stacked bar chart and breakdown table show exactly where time goes for that endpoint—controller logic, database queries, view rendering, and external HTTP calls—so you can see which layer is the bottleneck at a glance. The tab also surfaces your top five slowest SQL queries for that endpoint with normalized query text, average duration, and relative share of total DB time.

DeadBro now ships with a light mode. A toggle in the header navbar switches between light and dark, and your preference is saved so it persists across page refreshes and navigation.

Clicking a data point on any dashboard chart now opens Time Bro with a window that matches what the chart actually shows. On a 1-hour view each point represents one minute, so Time Bro opens that minute—same as before. On a 4h–24h view each bucket covers a full hour, so clicking shows you that entire hour of requests. On a 7-day or 30-day view you get the full day. The navigation arrows step by the same unit, and the request count in the modal now matches what you saw on the chart.

There is now a dedicated Problematic Requests page for each application, reachable from the sidebar. It lists every endpoint that has tripped a performance flag, tagged with one or more granular badges: N+1 (SQL count far above normal), Slow (duration well above your baseline), Memory (RAM spike), and High SQL (unusually high query count). The list loads incrementally as you scroll, so large histories stay quick.

The application sidebar now shows the version of the dead_bro gem your app is currently reporting. When a newer version is available you will see an amber Update available badge that links directly to the gem’s GitHub repository—so it’s easy to spot when you’re running something old without leaving the dashboard.

DeadBro now watches incoming requests and automatically surfaces Insights—notable patterns worth your attention—on your app dashboard and the account overview. We detect five types automatically: memory spikes (a request using far more RAM than your recent baseline), N+1 queries (SQL count far above normal for that endpoint), high-throughput windows (an unusual surge in requests over the current hour), P95 regressions (the slowest 5% of requests getting significantly slower than usual), and error bursts (five or more errors on the same endpoint in thirty minutes). No configuration required—Insights appear as they are detected and clear automatically after seven days.

You can turn on a public status page for a website check so stakeholders see current state, recent availability, and incident history without logging in. We also generate SVG badges you can drop into docs or READMEs to show live status at a glance. Configure both from the check’s edit screen when you want them.

On a slow or noisy request you can now line up behavior before and after a deploy—handy when you are validating a release or hunting a regression. The compare view sits alongside the existing request detail so you can jump between single-request context and a deploy-to-deploy diff.

When your app reports Elasticsearch or OpenSearch work for a request, the detail page now lists those operations with method, path, status, and time—so slow search clusters show up next to SQL, Redis, and the rest of the waterfall instead of disappearing into a black box.

We tightened several hot paths in how APM history is loaded and rendered, so common views stay quick as your data volume grows.

You can remove an APM application from your account when you no longer need it; removal is soft-deleted and finished in the background so you are not stuck waiting on a huge cleanup. Profile and account settings are now driven more consistently from the server, which makes the forms easier to evolve and keeps what you see in sync with what is stored.

Incident alerts wait briefly for the situation to stabilize before firing, and we skip notifications when a check was only down for under three minutes—enough to cut chatter from flaky networks and quick deploy blips without changing how we record downtime. Related background work was merged so maintenance-style jobs run on a simpler schedule.

Linked servers now collect resource-style metrics over time, with detail on the server page and optional threshold notifications when things look overloaded (including Pushover where you use it). Uptime probes send a DeadBroBot User-Agent so you can tell our traffic apart in your logs. We also iterated on the website checks experience with layout and validation polish.

The internal admin area for accounts, users, applications, blogs, and websites now supports search, pagination, and Turbo-driven listing frames so large tables stay usable. You will also see extra fields where they help support workflows, and uptime checks in admin gained sensible sorting.

Each website check now has its own notification setting, so you can mute noisy or low-priority endpoints without turning off alerts for everything else. Open a check’s Edit page from the uptime dashboard to choose whether that check should send email and Pushover when it goes down or comes back up. Your profile still controls how you receive those channels; the check decides whether this monitor participates at all.

There is a new dashboard for your whole account: see errors and traffic across your applications, how throughput looks over the last day for your busiest apps, recent deploys, and important logs—all in one place. You’ll find it from Dashboard in the sidebar (above Applications). Older bookmarks to the app dashboard still work and take you here.

Website checks now run against your linked server so results match your real setup. You can pause and resume checks when you need maintenance windows, see quick trend hints at a glance, and add or edit checks with clearer validation and on-page feedback when something needs fixing.

If you work in more than one account, the app now makes the active account obvious in the navigation so you can switch context with confidence.

New accounts start with incident email notifications turned off. Turn them on when you want email in the loop for downtime—so you only get the noise you choose.

Your applications list now includes a summary of how your account is using the product against your limits, so you can see where you stand without hunting through settings.

You can get incident notifications on your phone through Pushover, with optional alert sounds. Connect your Pushover user key in your profile and choose how you want to be notified. We also added Pushover to the Integrations page so it’s easy to discover.

We improved how older APM data is stored and retrieved behind the scenes, so the app stays responsive as you collect more performance history over time.

On request-type views, new traffic appears automatically without refreshing the page. New rows are briefly highlighted so you can spot what just arrived, and we simplified the table so it’s easier to read at a glance.

Charts on the requests view show fewer crowded axis and legend labels, so performance trends are easier to follow on a normal laptop screen.