Account Settings
Profile, team, API keys and danger zone in one screen — with the destructive panel last, well away from the everyday controls.
Notifications from the receiving end: the inbox you arrived from, per-event and per-channel control, and the push prompt asked after the decision rather than on arrival.
app/notification-settings-page.tsxnpx hoverlab add notification-settings-page
Or over MCP, from your editor's agent — no account needed.
Free to read, copy and install, for personal and non-commercial projects. Shipping it in client work or a paid product needs Pro ($79 once). The source lands in your repo and stops being ours — no attribution, nothing to upgrade.
What you were just interrupted by, then every control for deciding whether it happens again.
Ada Lovelace mentioned you in “Q3 roadmap”
Grace Hopper requested your review on #482
System Usage reached 80% of your monthly quota
Alan Turing invited you to the Platform team
Katherine Johnson replied to your comment on #470
Choose how you hear about each kind of event. Changes save as you make them.
| Event | Push | In-app | |
|---|---|---|---|
| Mentions & repliesSomeone @-mentions you or replies to your comment. | |||
| AssignmentsWork is assigned to you or reassigned away from you. | |||
| Weekly digestA Monday summary of what moved last week. | |||
| BillingReceipts, upcoming charges, and failed payments.A failed payment has to reach you somewhere you will see it. | |||
| SecurityNew sign-ins, password changes, and API key creation.Security alerts cannot be switched off. |
Your build usually takes about nine minutes.
No marketing, no digests, no re-engagement nudges — those go to email, where you can unsubscribe.
This asks your browser next. We will not ask here again.
Fire one to see the stack. Hover or focus a toast to hold it open.
The real page, rendered in your current theme — every section below is a live block, not a screenshot.
Only want one section? Open it and copy that block instead — browse Notifications.
/**
* Notifications, from the receiving end.
*
* `alerting-page` is the same subject for the person configuring the
* system. This one is for the person being notified by it, and the split
* matters because the two want opposite things: one is trying to make sure
* nothing is missed, the other is trying to make it stop.
*
* The inbox is first because it is the thing the user came here from.
* Someone opens notification settings immediately after being interrupted,
* with the interruption still on screen, and a settings page that opens on
* a grid of switches makes them go back and look again at what they were
* trying to turn off.
*
* inbox the bell panel, with the unread count in the accessible
* name rather than only in a coloured dot
* preferences per-event, per-channel — the coarse control
* matrix every event against every channel, with required rows
* locked and *explained*, which is the part that stops the
* grid reading as a broken switch
* push the soft ask, before the browser dialog you get one shot at
* toasts the least interruptive channel, and the one people forget
* counts as a notification at all
*
* The push prompt is fourth and not first, which is the entire argument of
* that block: asking for the permission at the moment of arrival is how you
* get denied permanently, and the browser gives no second chance. It
* belongs after someone has decided they want to be told things.
*/
import * as React from 'react'
import { NotificationInbox } from '@/components/notification-inbox'
import { NotificationPreferences } from '@/components/notification-preferences'
import { SettingsNotificationMatrix } from '@/components/settings-notification-matrix'
import { PushPermissionPrompt } from '@/components/push-permission-prompt'
import { ToastStack } from '@/components/toast-stack'
export default function NotificationSettingsPage() {
return (
<main className="min-h-screen bg-background text-foreground">
<section className="mx-auto w-full max-w-5xl px-6 pb-2 pt-12">
<h1 className="text-2xl font-bold tracking-tight">Notifications</h1>
<p className="mt-1 text-sm text-muted-foreground">
What you were just interrupted by, then every control for deciding
whether it happens again.
</p>
</section>
<NotificationInbox />
<NotificationPreferences />
<SettingsNotificationMatrix />
{/* Asked after the decision, not before it. */}
<PushPermissionPrompt />
<ToastStack />
</main>
)
}
components/ — each block page has its own copy button.app/notification-settings-page.tsx. The imports already point at @/components/…, so they resolve with no edits.The component, its props, the design tokens it expects and the command that installs it — as one prompt. Paste it into Claude, Cursor, v0 or ChatGPT and what they build around it will match the rest of the catalog instead of inventing its own system.
Profile, team, API keys and danger zone in one screen — with the destructive panel last, well away from the everyday controls.
Plan, quota meters and invoice history, with the upgrade prompt placed beside a bar that is nearly full rather than on the plan card.
Consumption in the order the questions arrive: the overage warning first because it is time-critical, then the meters, then what actually happens at each limit.
Billing history laid out for finance rather than for the user — a retrieval screen, so the table leads and the payment method comes last.
The admin screen a security questionnaire is really asking about — seats with the bill shown first, invitations, scopes split from bundles, sharing stated as its consequence, live sessions, and the audit trail underneath.
Both directions, because only one of them is usually built: a radiogroup with the prorated charge announced as it changes, and a cancellation with the end date, what breaks, and one honest alternative offered once.