Geist Design System

Project Banner

Used for temporary, project-wide notifications that require resolution

Success

For positive, temporary mitigations put in place to protect a project, e.g., Attack Challenge Mode

Warning

When a project is in an exceptional state which requires non-immediate action to exit, e.g., during a rollback

Error

When a project is approaching or experiencing critical downtime which requires immediate attention, e.g., when payment is overdue

Best Practices

When to use

  • Use Project Banner for project-wide states that need resolution: overdue billing, an active rollback, attack mitigation, an expiring trial blocking deploys.
  • Pick Note for inline contextual messages tied to a single field or card, Toast for transient acknowledgments, Modal for confirmations.
  • Match variant to severity: error for critical downtime or payment-blocking states, warning for an exceptional state with non-immediate action, success for a positive temporary mitigation, gray for routine project-wide notices.

Behavior

  • Project Banner is non-dismissible by design. If the message can be dismissed without resolving the underlying state, it isn’t banner-worthy; move it to a Note.
  • Show one Project Banner at a time. Stacking competing banners drowns the most urgent state.
  • Always pass a callToAction that resolves the state. A banner with no route is a dead end.

Content

  • label is one sentence in sentence case that names the impact: Your Pro trial expires in 3 days. Don’t open with Heads up or apologetic preambles.
  • callToAction.label is Title Case Verb + Noun and points at the resolver: Update Payment Method, Reactivate Project, Review Tokens.
  • Name the affected entity when the project context isn’t obvious from the surrounding chrome (Production deployments are paused on my-project).
  • Don’t encode severity in the copy with emoji or interjections; the variant carries that signal.