Add webhooks to the UI

[charliepark]

This PR adds the Alerting sidebar and the two tabs that nest under it, Alerts and Receivers. It also then shows the list of Receivers, all of which are Webhook Receivers for the present and near-term future. The webhook receiver creation form uses a richer input for the alert subscriptions that Ben created in #3326.

There's an Alerts list that @fakemonster is working on separately.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
console	Ready	Preview	Sep 3, 2026 7:28pm UTC

[hawkw]

I like the UI, it looks great! Let's try to keep the language consistent with the terminology we use in the documentation, API, and the CLI.

In particular, we should always say "alert" and "alert class" rather than "event" or "event class". In the API and public documentation, the term "event" is only used in the abstract (i.e. "Alerts provide a notification when an event has occurred in the system"); it's not the name of an object in the API. I think the only place where we refer to them as "events" is in RFD 538, which...should really be updated to reflect the terminology used in the product. My bad.

Also, I'd generally prefer to always refer to an endpoint that receives webhooks for alerts as a "webhook receiver", not a "webhook". Elsewhere, I've seen the term "webhook" used to refer to both the request itself and the thing that receives that request, which I think is a bit confusing, so I'd rather we use the terminology consistently.

Sorry for being persnickety about names, the UI looks awesome!

[charliepark]

I like the evolving audit-log-ish view.

[fakemonster]

The audit log styling would give it more of the feel of a timeline of immutable events.

Agreed, this is where I had actually started, but since the audit log isn't merged yet, I opted to just do the basic thing here instead of straddling two branches. Once we've actually got the audit-log branch merged to main, we can/should hop over to it. Though perhaps as a separate PR? This seems awfully close to landing already, and if alerts is no longer the landing tab, it's not too much of a dead end. I can pick it up once I'm back in, I've already got a bit of a branch refactoring a common list component out of the audit log branch. Would be a good moment to introduce filtering by alert class

[david-crespo]

I lean against badge here.