Shard alert source rate limits

Alert sources have been updated to enable you to specify a query expression to extract a value from incoming alert payloads to shard rate limits on. This is useful when you want to separate rate limits for incoming alerts on a source so that one type of alert does not consume the source's rate limit for all other alerts coming from it.

One example of when you might want to do this is when you have lots of low priority alerts that you are happy to be rate limited, but significantly fewer high priority alerts which you need to not hit the limit.

Each individual shard will have a separate 120/min rate limit.

On-call

You can now filter alerts at the alert source

Now, we let you filter out alerts within the source (as well as the route). This is the earliest opportunity for us to filter out alerts and means unwanted alerts don't clog up your Alerts list.

See full documentation for support here.

Improved Terraform for escalation paths

We've released a new beta resource for escalation paths: incident_escalation_path_beta!

The main changes are:

• Plan time validation of an escalation path.
• Added dedicated priority_one_of and working_hours_active conditions you can use instead of a full conditions block.
• Changed the schema from nested nodes to a flat map of node sequences, so there's no longer a maximum branch depth cap!

As ever, we may change this beta resource in backwards-incompatible ways, and the old incident_escalation_path resource is still available.

Escalation paths can now hand over to other escalation paths

You can now end an escalation path with a reassign step, which hands an unacknowledged escalation to another path. The original escalation expires and a new one starts on the target path.

Define one "fallback" path and point several team paths at it. Reassign steps can follow a retry node, so a path can try its own on-call a few times before handing over.

A reassignment timeline item is shown on the original escalation and the reassigned escalation (so you can navigate between them).

A few things worth knowing:

• The original escalation is expired rather than resolved (because nobody acknowledged it)
• You can configure escalation paths that reassign in a loop
• Escalations that reassign to more than 10 escalation paths will auto-expire instead of reassigning - this is to prevent infinitely looping escalations

Investigations

Investigations homepage shows trends

Our investigations homepage shows a 90 day performance window which means accuracy and engagement figures are averaged over this period. We’ve added trends for accuracy and engagement, so it’s more clear when things are trending upwards.

Telemetry RBAC

We've split out permission to manage telemetry into granular RBAC scopes, as well as introducing team-based permissions per telemetry data source.

Customers can mark specific sensitive data sources as 'restricted' to limit which users and API keys have access to query them.

View our external loom as well as documentation in the help centre.

Nexus

Nexus now tells you when something's broken

Issues with your Nexus setup will now be clearly surfaced on the Nexus homepage, and our health score more accurately reflects any problems. So far, we will inform people of:

• Broken connections to Code and Documentation providers (e.g. Github, Gitlab, Notion)
• Broken connections to Telemetry sources (e.g. Grafana, GCP, Datadog)
• Specific Telemetry health issues (e.g. low query success rates)

Response

Private incidents in Insights

Every Response Insights dashboard now has a toggle for any organization with at least one private incident. Turn it on and the graphs include the private incidents that you have access to. To be explicit: no new permissions, no new access. You can only see what you could always see but now on graphs.

This is great if you:

• Need trends across all your organization’s incidents for regulatory or board reporting
• Are a team like Security where every incident is private, and Insights was therefore an empty experience
• Want to see time spent on incidents including private ones, so you can check on workload

Freshservice ITSM Integration

We now support Freshservice as an issue tracker, meaning you can:

• Create incident tickets in Freshservice which update as your incident progresses
• 2-way sync so comments on the ticket come into the incident channel, and we post updates back to the ticket
• Create follow-ups in Freshservice (which will be children of the incident ticket, if there is one)

Co-hosts for Zoom incident calls (Beta)

You can now add co-hosts to Zoom calls we create. This lets you do things like "the incident commander and comms lead are co-hosts and can manage the bridge call" or "everyone in the IRM team are automatically added as co-hosts of the incident call.”

Platform

Edit your catalog from inside Settings → Teams

We've had feedback in the past that setting up teams isn’t the most intuitive. So, we've done some work here to hopefully make it simpler:

• You can now edit your Team catalog type without leaving Settings → Teams - it's all there for you. You can also create new teams (assuming they're managed in the dashboard)
• You can still edit everything in catalog, if you're someone that prefers that model
• We've fixed a ton of tiny bugs that we found along the way

Policies now have a page for viewing and dismissing violations

Until now, clicking on a policy anywhere in the product (the policies list, a Slack/email policy report, the needs-attention tiles) dumped you straight into the edit form. This was a bit much if you just wanted to see what the policy is triggering and dismiss some violations. Now every policy has a read-only view page showing its violations:

• Summary cards up top: current, overdue, due soon and unassigned counts, click one to filter the table
• A searchable table of every violation, with the incident or schedule, the assignee and when it's due
• Bulk dismiss and restore violations right from the page (permission-gated, obviously)
• It only needs the view permission to access, so anyone in the organization can see the list, but only those with the correct permissions can dismiss.

Terraform workflows polish

We've made some big improvements to the incident_workflow Terraform resource (documentation and examples), and some small improvements to the resource itself!

There's now:

• More examples, and all the examples showcase proper use of the provider.
• We've also copied over the nicer parameter binding syntax we introduced for alert sources,
• There's now exhaustive lists of what values each attribute can contain where possible.

This all should make Terraform workflows much easier to generate using code agents.

API

We’ve been adding new items to our public API to allow you to do even more than before. This includes:

• Updating and deleting schedule overrides
• Acknowledging and snoozing escalations
• Attaching alerts to incidents, and detaching them
• Creating incident updates

In addition, we now have an automatically generated and maintained API changelog in our docs. It's also been backfilled back to January, so there's a lot in there.

Status Pages

Control your status page component history

After you've added a new component, you can now choose where your history 'starts' so instead of having grey bars, you can decide to show it as green from a chosen point in time.

What else we've shipped