A callout that sits in the page is a different job from a message that fades away. shadcn’s alert is a callout for user attention, and its page says nothing about when to use one, so the choice of variant and placement is yours to make.
What the shadcn page covers
The page describes the component as “Displays a callout for user attention.” The install command is pnpm dlx shadcn@latest add alert, with tabs for npm, yarn and bun. The usage section imports Alert, AlertAction, AlertDescription and AlertTitle from @/components/ui/alert. The page’s usage example places an InfoIcon inside the Alert, and its intro example also imports CheckCircle2Icon.
The examples cover a basic alert, a destructive variant, an action, custom colors and a right-to-left layout. The destructive variant is set with variant="destructive" on the Alert.
The page does not say when to use an alert. It also does not say whether an alert stays on screen or can be closed. Those two points matter for your design, so the rules below cover them, and they are labelled as ours.
Build an alert with a title and a description
An alert has a short title and a description that explains what the reader should know or do. Put the icon first, then the title, then the description. The page’s usage example follows the same order:
import { InfoIcon } from "lucide-react"
import { Alert, AlertDescription, AlertTitle } from "@/components/ui/alert"
export function PlanLimitNotice() {
return (
<Alert>
<InfoIcon />
<AlertTitle>You are on the Starter plan</AlertTitle>
<AlertDescription>
Upgrade to add more projects. Your current projects are unchanged.
</AlertDescription>
</Alert>
)
}
The title says what the situation is. The description says what the reader can do about it, or what stays the same. Keep both short. A reader who scans the page should understand the callout from the title alone, and the description is there for the reader who wants the detail.
Match the variant to the risk
The default alert is for information the reader should notice, such as a plan limit or a scheduled change. The destructive variant is for a problem that needs action, such as a payment that failed or a sync that stopped. Our rule is that destructive means the reader must act, and information means they should know. Using destructive for routine news trains readers to ignore red.
Keep the variant consistent across the product. If one plan limit is destructive on one page and informational on another, readers stop trusting the color.
Place the alert next to what it is about
An alert about a project belongs at the top of that project, not at the top of the whole app, so the reader connects the message to the thing it describes. A notice about billing belongs on the billing page. Place it above the content it affects, and keep it out of the way of forms the reader is already filling in.
If an alert needs a button, the page’s usage example includes AlertAction. Check that example’s View Code panel for where the action sits inside the alert, and keep the action to one clear step. Two buttons in a small callout make the reader choose between two outcomes they may not understand.
Decide whether it stays on screen
The page does not say whether an alert stays visible or can be closed. If your alert must stay until the reader acts, leave it in the page’s flow and do not add a close control. If it can be dismissed, add that behavior yourself, and store the dismissal so the alert does not return on the next visit unless the situation changes.
Our rule is to keep an alert on the page while its condition is true. A plan limit stays until the reader is on a plan that has room. A payment problem stays until the payment succeeds. Removing the alert early because a reader scrolled past it hides a problem they still need to fix.
Do not use an alert as a toast
A toast fades after a moment and suits a confirmation, such as “Profile saved”. An alert stays and suits a condition, such as “Your plan is full”. Using an alert for a confirmation leaves a stale message on the page after the action is done, and using a toast for a condition hides it before the reader has acted. The two components are not interchangeable, even when both can show a short title.
The toast guide covers the temporary message, and the dialog and sheet guide covers a choice that must happen before the reader continues.
Test before you ship
Check these on the real page, not only on the component:
- Tab through the alert. If it has an action, the action should take focus and press with Enter.
- Read the alert with a screen reader. The title and the description should read in order, with the icon treated as decoration.
- Check the destructive variant against the default side by side. The difference should be clear without relying on color alone.
- Remove the condition, then reload. The alert should disappear when the condition is no longer true.
- On a 390px phone, check that the icon, the title and the description wrap without pushing the page content out of view.
Run the phone check last, after the wording is final. A long title can wrap beside the icon and move the description down the screen.
Where OTF stands
If you want an alert or a callout already built into a product, we cannot point you to one. We checked the SaaS Dashboard, Booking, Fitness and Arcade kit pages for alert, callout and banner terms, and none of them names an alert component. The SaaS Dashboard page lists “Inbox & notifications” as a feature, which is a feature of the product and not an alert component.
The pricing page lists the Full-stack kits at $99 each and the Everything Bundle at $149, both as one-time payments, and it offers a live demo before you buy. Check each kit’s repository for the components it ships before you rely on any of them. If you are choosing a starting point for a product, the pricing page is the place to compare kits side by side: OTF pricing.
Sources
- shadcn/ui, Alert: https://ui.shadcn.com/docs/components/alert
- OTF pricing: otf-kit.dev/pricing