What shipped

Maple alerts now cover the whole path from a firing rule to the person who fixes it. Everything below is in the Alerts hub.

Acknowledge an incident

Click Acknowledge on an incident or in the inbox, or on the alert card in Slack or Discord, to tell your team you are on it. While an incident is acknowledged, reminders stop. If it gets worse and moves from warning to critical, it pages again. When the incident already paged PagerDuty, the acknowledgement is sent there too. The inbox lists unacknowledged incidents first, and the incident timeline records who acknowledged it and from where.

Escalation chains

A chain is a list of steps: notify these destinations or people, then wait a number of minutes for someone to acknowledge before the next step. For example, “post to #alerts, then page the on-call after 10 minutes, then the team lead”. A chain can repeat. Build chains on the Routing tab and attach one to a rule’s warning or critical tier. Acknowledging pauses the chain, and the incident page shows which step it is on and when the next page goes out.

On-call schedules

The new On-call tab holds your rotations. A schedule has a time zone and up to five layers, each rotating its people daily, weekly or every few hours, optionally only in some hours or days (weekends, or 22:00 to 06:00). An override covers a shift for someone else. Each schedule has a week calendar with the final rotation and its overrides, and the inbox shows who is on call now. An escalation step can page “whoever is on call” on a schedule, by email, Slack direct message or Discord direct message.

Silences

Silence alerts for a deploy or a planned migration without turning rules off. Silence one rule or one incident’s group for 1 hour, 4 hours, until 09:00 or a custom end, or create a silence on the Silences tab that matches rules by service, environment or tag. Rules keep evaluating while silenced. If an incident is still open when the silence ends, its page goes out then.

Maintenance windows are recurring silences, such as “every Sunday 02:00 to 04:00 in Europe/Berlin”, and keep planned downtime out of anomaly baselines. For now they are set up through the API and MCP; the dashboard comes next.

Anomalies route like alerts

Detected anomalies now page through alert rules, so they get destinations, warning and critical tiers, acknowledgement, silences and escalation like any other alert. Open anomalies are the Anomalies view of the inbox, and an anomaly rule can be scoped to services, environments and signals. Paging on anomalies stays off until you add a destination.

All of this is available from the API and the MCP server as well, so an agent can ask who is on call, acknowledge an incident or silence a noisy rule.

Analyze → Users lists the end users of your product: everyone your SDKs identify, through identify() in the browser or user.id / enduser.id on spans. It is now on for every organization.

• The directory shows each user’s sessions, errors and requests, when they were last seen, and where their requests come from (web, mobile, API or MCP). Filter to users with errors or with replays, and group users by the group you pass to identify(), such as their company.
• A user’s page shows their identity, traits and devices, and tabs for activity, session replays, product events and the MCP sessions they ran, merged into one timeline.
• Issues show how many users an error affected, and a user shows the errors they hit.

Use it to answer a support ticket (“what did this customer see?”) or to check who a bad deploy reached. The same data is available from the /v2/users API and the list_users and inspect_user MCP tools.

You can now define service level objectives in Maple. An SLO covers one service’s incoming requests, optionally limited to some environments, and has:

• an SLI: availability (requests that did not fail) or latency (requests faster than a threshold from 50 ms to 10 s);
• a target, such as 99.9%;
• a rolling window of 7, 28 or 30 days.

Each SLO alerts on how fast it spends its error budget, not on single spikes. A critical page fires when the budget burns at 14.4 times the sustainable rate over both the last hour and the last 5 minutes. A warning fires at 6 times over both the last 6 hours and 30 minutes. A brief blip does not page, and the page clears as soon as the burn stops. The notification says which windows are burning and how fast. A gap in incoming data holds the alert where it is instead of resolving it.

Find SLOs under Alerts → SLOs. Each SLO’s page shows the SLI against the target, the budget left, the budget over time, the burn rate of each window, and its incidents. SLOs are also available from the /v2/slos API and MCP.

The metrics query builder now aggregates in two steps, the way metrics are usually read:

1. Within each time series: avg, sum, min, max, count, latest, rate or increase over each interval.
2. Across time series: sum, avg, min, max or count, grouped by up to five fields at once, mixing service.name, metric attributes and resource attributes.

So “memory summed over pods, by namespace and job” or “requests per second by namespace and host” is now one builder query instead of SQL.

This also fixes grouped metric charts:

• Series that report more often no longer weigh more in an average.
• A grouped line no longer jumps between services’ values from one bucket to the next.
• A rate in a widget no longer comes out 60 times too low on a one-minute bucket.
• Pie, table and bar breakdowns now agree with the line chart they came from.

Alert rules can now notify more of the tools your team already works in:

• Microsoft Teams. Alerts post to a channel through a Workflows webhook, as a card with the state, severity, group, chart and Open in Maple and Ask Maple AI buttons.
• Google Chat. Alerts post to a space as a card with the chart. A resolve or reminder replies in the thread its trigger started.
• incident.io. Maple raises an alert on an HTTP alert source and resolves it when the incident clears. The rule, severity, value and group come along as metadata your routes can match on.
• Linear. Instead of a message, Maple keeps one issue per rule and group in the team you pick. A repeat fire comments on it, a resolve comments and leaves it open for your team to close, and a fire within 24 hours of closing reopens it. Add Linear to a rule’s critical tier only to ticket just the serious incidents.

The Discord integration is now open to every organization, and the Maple bot is available in Hazel. In both, alerts post to a channel and you can ask Maple questions in a thread.

Every destination has a Send test button. Set them up from the Routing tab in Alerts, and see Notification destinations for each one.

Three changes to how errors become issues:

• Merge issues. Select issues on the Errors page and choose Merge, then pick the one to keep. Its count and builds include the others, and their future occurrences land on it. A merged issue’s page links to where it went and has Unmerge, which hands back exactly the occurrences it brought. Merging is also available from the API and MCP.
• Set the grouping in code. Put a maple.fingerprint attribute on an error span or its exception event, and every error in that service with the same value becomes one issue, whatever its stack or message. Use a fixed name for the failure, never a per-request value.
• Grouping by your own code. When a stack has frames from your application, frames from dependencies and the runtime no longer affect the grouping. An error thrown inside a library now groups by the code of yours that called it. Existing issues carried over to the new grouping with their state, history and counts.

See How errors are grouped.

If you run an MCP server, Explore → MCP servers now shows how agents use it. Maple reads the spans your server already emits under the OpenTelemetry MCP conventions. There is no extra SDK or second call to make.

• The list has every service that answers MCP tool calls, with calls, failure rate, p95, tool count, top client and a volume sparkline.
• A server’s page charts calls, failures, latency and clients, and breaks them down by tool, client (Claude, Cursor and so on), failure kind and MCP method.
• A tool’s page groups its errors by type and message, and lists the slowest, failed and recent calls, each linking to its trace.
• Sessions group a server’s requests by MCP session, in order, linked to the agent session that made them and to the user behind it.

A server that doesn’t send what a view needs gets a checklist of the attributes to add, not an empty table.

Connecting your own agent to Maple is also quicker: the Connect panel in the top bar has a copy-paste command for Claude Code and one-click install links for Cursor and VS Code.

Read more in MCP servers.

Maple’s ingest endpoint now accepts OTLP over gRPC, on the same host and port as OTLP over HTTP. Java, .NET, Python and the OpenTelemetry Collector often default to gRPC, and they can now send traces, logs and metrics to Maple as they are configured:

export OTEL_EXPORTER_OTLP_ENDPOINT="https://ingest.maple.dev"   # https://ingest.eu.maple.dev for EU organizations
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer YOUR_INGEST_KEY"
export OTEL_EXPORTER_OTLP_PROTOCOL="grpc"

gzip compression, request limits and ingest keys work the same as over HTTP. Errors come back as gRPC status codes, and the ones worth retrying are UNAVAILABLE, which exporters already retry.

See the Ingest API reference.