What shipped

Product events are now a full dashboard source, next to traces, logs and metrics. Before this, a funnel was the only widget that could read them.

In any query panel, pick Product events as the source. You can chart an event count as a line or a stat, break events down by event name, page or property, count distinct people or sessions, list recent events, and use event counts in formulas. The Add widget picker has presets for Top Events, Events by Page and Recent Events. Alert rules accept product event counts too.

Funnel drop-off

In a funnel widget’s settings, set View to Drop-off. Each step shows who reached it and who left since the previous step, with the step’s conversion and the median time between steps. Hover a step for p50 and p90 timing and the events the people who left went to next.

Paths

The new Paths widget shows what people do in the steps after an event or page, or before it. Choose the anchor, the direction, up to five steps and how many branches to name per step.

Get started with Product events.

The time range picker now has a timezone selector in its footer. Until now Maple always showed times in your browser’s zone, which made it hard to line up an incident with a teammate’s clock or with logs stamped in UTC.

Open the picker and choose Timezone. System and UTC are pinned at the top, and you can search every other IANA zone by city, region, UTC offset (utc+5:30), or the current time there (11:20). Your choice is saved and applies across the app.

The selected zone is used on every page with a time range picker:

• chart axes and tooltips
• the range label and the custom-range calendar
• day-aligned presets such as today and 7d, which start at midnight in that zone
• hover timestamps on traces, logs, errors, alerts, services, infrastructure, metrics, releases, replays and agent sessions

Pages without a time range picker, such as settings and billing, keep your browser’s local time.

The new Releases page answers two questions after a deploy: what shipped across your services, and did it change anything.

• A swimlane per service shows one dot per version, placed when it first served traffic.
• A table groups releases by commit and compares each version’s error rate and p95 latency against the rest of the service in the same window, so a canary is measured against the version still running beside it.
• Each release has its own page with the commit, the service’s golden-signal charts (with a toggle for this version versus the others), and the error issues that are new, regressed, or still occurring on it.

Maple identifies a release by commit, read from the vcs.ref.head.revision resource attribute. Set it to the commit SHA your service was built from. See OpenTelemetry conventions.

Releases is rolling out gradually. Once it’s on for your organization, it appears in the sidebar under Monitor.

Maple now keeps an append-only audit log for every organization. It records each action taken in Maple from the dashboard, the public API or MCP, whether it was allowed or denied, along with every read of telemetry and session replays. Each entry names the user, API key or agent that performed it.

This gives you a record for security reviews and compliance audits: who changed an alert rule, which API key queried logs, or which agent read a session replay.

Admins find it under Settings → Audit Log. You can filter by actor type and outcome, see the reason for denied actions, and open an entry to see what changed, with before and after values. The same entries are available from the API at GET /v2/audit_log with an API key that has the audit_log:read scope. Entries are kept for six years.

See Data retention and the API reference.

You can now narrow the Logs page to a single trace. Paste a 32-character trace ID, or a full W3C traceparent header copied from your own logs, into the search box. Maple turns it into a trace filter, shown as a chip you can remove. Before, the pasted ID ran a text search against log messages and returned nothing.

The filter lives in the URL, so /logs?traceId=<id> is a link you can share. The log list and the volume chart both scope to the trace.

The trace page also gained a View Logs button in its header. It shows how many logs the trace produced, appears only when there are some, and opens the Logs page already filtered to that trace.

See Logs for the search syntax.

Attaching a pull request to an error issue used to mean leaving Maple, finding the PR on GitHub and pasting its URL. Now Attach opens a picker of recent pull requests from your connected repositories. Maple preselects the likely repository, for example the one whose name matches the issue’s service, and leaves the choice to you when it isn’t sure.

Pasting still works: a full URL, #123, or a bare number. It is also the way to attach a pull request from a repository you haven’t connected.

This also fixes a gap in fix verification. A pull request that had already merged when you attached it never started verification, so the issue stayed In review indefinitely. Maple now looks up the pull request when you attach it and starts the verification window right away if it has merged.

The picker needs the GitHub integration. See Fix verification for how the window works.

The Traces page used to list entry-point spans, so a request that crossed four services appeared as four rows. It now shows one row per trace, with the real span count in a new Spans column, the full wall-clock duration, and every service the trace touched.

Single-span traces that aren’t entry points, such as mobile screen breadcrumbs and orphaned client spans, are now hidden by default because they crowded out real requests. Nothing is hidden silently: the table footer says how many traces were hidden and has a link to show them, and the Hide Single-Span Noise toggle in the sidebar turns the filter off.

Mobile screen traces also show their screen name, so they no longer read as a column of identical ui.screen rows.

See Traces for all list filters.

You can now route alerts to a Telegram chat, group or channel. Until now the only option was the generic webhook destination, whose payload Telegram’s Bot API can’t read, so alerts could not reach Telegram at all.

On the Alerts page, open the Destinations tab, click Add destination and pick Telegram. You need a bot token from @BotFather and the ID of the chat the bot posts to. Maple checks both when you save, so a token that is wrong, or a bot that was never added to the chat, is caught then instead of when a real alert fails to arrive. The token is encrypted at rest like every other destination secret.

Each alert message has Open in Maple and Ask Maple AI buttons, and shows the alert chart as its link preview.

See Notification destinations for step-by-step setup.