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 (UTC)
console	Ready	Preview	Aug 28, 2026 9:44pm

[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]

Thank you for all of the copy suggestions, @hawkw!

[hawkw]

I'm not sure if this is the right place to review the alert list that @fakemonster is working on, but I have some notes:

1. I feel like it might be a bit nicer to put the timestamp first in the table, followed by the class. Something a bit more like the audit log.
2. We should probably also include the alert's UUID in the table, since that's how you would distinguish between two alerts with the same class, and you'd potentially want to be able to copy that etc.
3. Maybe we can also use the same styling as the audit log, rather than the "table of resources" styling?
4. Also, I like that in the audit log, the entire row is clickable to display details on that entry, rather than having to click on the three vertical dots at the side of the row.
5. At least on a large, high-resolution display, this feels a little bit...sparse.

Maybe we should left align the columns and then use the rest of the space for an "all in one line" display of the payload JSON, which it's fine to truncate? if the viewer wants to see the full json they can click on the alert's details 6. It seems like in #2849, @david-crespo is highlighting the JSON, like this:

It would be nice to reuse that here.
7. I feel a bit unsure about whether we should be typesetting the alert classes (both in the alert list and the webhook receiver editing UIs) in UPPERCASE, since the canonical strings are always lowercase, and if someone copies an UPPERCASE.ALERT.CLASS out of the UI and tries to use it as a subscription to that alert class in the API, it...won't work. This could be pretty unfortunate.

[hawkw]

The alert receivers UI is looking awesome, thanks for applying my suggestions! One note: when sending a liveness probe to a webhook receiver, we might want to include a chekcbox for whether to resend failed deliveries if the prove succeeds in the popup?