More powerful workflows

We’ve shipped a bunch of new workflow-related features including:

• Creating a workflow off of alert creation and resolution
• Storing secrets for workflows
• Signing workflow requests
• Better editing for webhook steps in workflows

Alert trigger for workflows

You can now configure a workflow to run whenever an alert is created or resolved. For example, you can automatically send a webhook with a custom payload when your alert is resolved.

This is helpful if you would like to keep an external system, such an internal tool or a system we don’t have a native integration with, up-to-date with incident.io.

Secret store for workflows

Customers can now store sensitive strings as secrets, and reference them when sending webhooks from workflows!

In Settings there is a new Secrets page where you can view your organization's secrets and their details. With the secrets.manage privilege (which Owners and Admins have by default) you can also create, update, delete, and rotate a secret, which will add a new version. On top of that, you can also check a secret's full version history and rotate secrets via the public API.

A secret can also be owned by a team, and there's a matching secrets page in the Team Settings menu where members can see their Team's secrets.

After creating a secret you can insert it as a variable in the headers for a webhook. We only display the secret name in the UI, so sensitive things like API keys or bearer tokens no longer have to sit there in plaintext. Secrets will only appear in the picker if you have the secrets.use privilege, which Owners and Admins have by default.

Sign workflow webhook requests

Customers can now verify that a webhook request actually came from us. They can either use one of their new secrets for this, or we can generate a random signing secret for them.

Improved editor for webhook steps in workflows

In workflows, you can set up a step to send a webhook, and you used to configure the request body in a rich text editor. We know that configuring JSON in the rich text editor wasn’t a great experience because it didn't provide syntax highlighting or validation. We've now introduced syntax highlighting and validation when we detect the body is JSON, so you can catch issues at edit time rather than waiting for the workflow to run.

Refreshed Insights dashboards

We’ve been uplifting our Insights dashboards, with our most recent work improving the MTTX, Follow-ups, Time spent on incidents and Alerts dashboards. Within each of these you’ll notice:

• Data is now near real-time so you can get a more up-to-date view of what’s going on across your organization
• You can drill down into specific incidents or users for even more visibility
• Graphs are polished up (just check out the fresh color palette on Time spent on Incidents dashboard)

Mean time to resolve alerts graph

While we were at it, we’ve added a new mean time to resolve (MTTR) graph for your alerts in the Alerts dashboard. You can group based on alert attributes (ie. teams, features, services) and deep dive on specific data points to see exactly which alerts are referenced.

More actions with the agent

We've filled some of the most requested gaps in what the incident agent can do. Across all surfaces the agent can now also:

• Set & suggest incident timestamps: Read and set timestamps, and suggest them on request
• Suggest custom fields: You can always set them directly, but now the agent can suggest them on request, so ambiguous values get proposed for confirmation
• Resolve incidents: Directly across all surfaces; if required fields or timestamps are missing, the agent can suggest them as part of resolving an incident
• Escalations: For organizations with on-call, we now support direct escalations and escalation suggestions
• Team-aware follow-ups: When the agent creates a follow-up it can now set the assigned team

Policies can run on private incidents

Now you can opt individual policies in to run on private incidents. We will default the option to run a policy on private incidents to off for any incident-based policies (ie. follow-ups, post mortems).

If you use policies on private incidents, we’ll only notify people of policy violations if they can see the related incident. And, we only show violations in the dashboard to users who can see the related incident.

Team-owned catalog types

The catalog, for most customers, contains the source of truth for many things relating to their organization. Previously, making changes to catalog types and their entries required global permissions, which meant you could change any catalog type or any of their entries.

Now, you can set more granular permissions on the catalog. You can set which teams own which catalog types, then set up team permissions to restrict who can manage those types to only teams that own them. These restrictions extend to catalog entries too.

For customers who manage their catalog using GitHub, Terraform or the public API, you can apply team-scoped permissions for managing the catalog on your API keys, restricting API keys to only modify catalog types (and their entries) for teams they're scoped to.

Check out more in our help docs here.

HTTP alert sources now support query params

Our HTTP and custom HTTP alert sources now let you pull through query parameters to set alert attributes. This is helpful for organizations that have used other paging providers before moving to our On-call. Using query params allows you to have varying URLs still but consolidate configuration to less alert sources (versus an alert source per team or service).

Dash0 alert source

While you could integrate with Dash0 with our HTTP alert source, we now have a native alert source. This means you can create incidents and escalate from Dash) directly.

inc command line tool

We now have a command line tool (CLI) called inc. You can use our CLI to access and interact with our public API in a nice and polished format. This can be used directly to pull down information like incidents, schedules, escalations, or can be used when writing scripts, cron jobs, and CI actions. You can find it on our Github.

# What's on fire right now
inc incidents list --status-category live --fields reference,name,severity,incident_status

# Who's on call for a schedule today
inc schedules list
inc schedules entries 01H... --from 2026-07-20T00:00:00Z --until 2026-07-21T00:00:00Z

# Page someone from the terminal
inc escalations create --title "Database latency spike" --escalation-path-id 01H...

The scripting/jq crowd:
# Closed incidents this month, counted by severity
inc incidents list --status-category closed --jq 'group_by(.severity.name) | map({severity: .[0].severity.name, count: length})'

# Pull a post-mortem as markdown, straight into a doc
inc post-mortems content 01H... > postmortem.md

Please note, the MCP is our recommended way of interacting with our platform. The CLI exists as an alternative, but the MCP is more token efficient and optimized for LLMs.

What else we've shipped