CSS — StatusDashboard Docs

Custom CSS injects into every eligible public page on your status dashboard after default styles load. Override fonts, spacing, or hide elements when you need precise control beyond the primary color picker.

Common uses

Custom CSS is injected into a <style id="sd-custom-css"> tag in your status dashboard's <head> after the page's default styles load, so rules you write generally take precedence over page defaults. It applies across all eligible public pages and persists when visitors navigate between routes in the same session.

If you only need to change the dashboard accent color (hyperlinks, primary buttons, focus rings, and similar highlights), use the Primary color picker in the Branding tab instead. It applies across eligible public pages and does not require writing CSS. Custom CSS is better suited when you need to override other styles or want finer control beyond the accent color.

Override colors, fonts, or spacing to match your brand
Style custom Header and Footer HTML, including light/dark variants
Hide or restyle platform elements (for example nav[aria-label="Dashboard status bar"] on the Header page)
Add custom animations or transitions
Load a web font via @import from fonts.googleapis.com

Example — brand font and action bar styling

@import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap');

body {
  font-family: 'Inter', sans-serif;
}

nav[aria-label="Dashboard status bar"] {
  background-color: #f1f5f9;
}

.dark nav[aria-label="Dashboard status bar"] {
  background-color: #1e293b;
}

To override the tenant accent color in CSS instead of the picker, target the --color-brand-* variables set at runtime when Custom branding is enabled. See Primary color for what the picker controls.

Safe styling practices

Custom CSS is added after built-in styles, so your rules can win over ours. That is intentional for branding, but wide selectors change the whole page, not only your header or footer.

Start with class names you control in Header and Footer HTML. Avoid global rules on *, button, a, or short layout class names unless you mean to restyle the entire status dashboard.

Scope to your markup

The most reliable pattern is to pick a prefix or class (for example sd-custom-header and sd-custom-footer) in your Header and Footer HTML, then write CSS that starts with those selectors. Your styles stay on markup you own and are much less likely to disturb service lists, subscribe forms, or the action bar below your header.

Patterns that often break the page

Global resets — Rules on * or broad changes to html / body (margins, padding, box-sizing, display, or width on everything). Setting font-family on body is usually fine; resetting spacing on * usually is not.
Built-in class names — The status dashboard uses many short utility classes for layout, spacing, and visibility. Redefining names such as .flex, .grid, or .hidden can break navigation, status cards, tabs, or dialogs site-wide. Add your classes in custom HTML instead of overriding ours.
All buttons or all links — Unscoped button { … } or a { … } also styles Subscribe, Support, SSO, and in-page links. Nest those rules under your header/footer classes, or target one region (for example nav[aria-label="Dashboard status bar"] when you only mean the action bar).
Accent and status colors — Prefer the Primary color picker for brand highlights. Green, red, and blue on the page often mean operational, incident, or maintenance state. Blanket color overrides can make status hard to read.
Heavy use of !important — Makes conflicts harder to undo. Prefer more specific, scoped selectors first.

Verify after you save

Spot-check the home page, an event detail page, and Subscribe or Support (if enabled) in light and dark mode. If built-in layout looks wrong, remove the broadest rules first and restyle with scoped class names.

Tailwind CSS

The status dashboard is built with Tailwind CSS. Utility classes already used by the platform will be present in the compiled stylesheet. Because Tailwind only generates CSS for classes found in source code at build time, less-common utilities you reference in custom HTML are not guaranteed to be available.

For reliable styling in Header and Footer HTML:

Fixed look: inline styles work and stay the same in light and dark mode.
Theme-aware look: add your own class names in HTML and define light/dark rules here (see below).

Do not depend on Tailwind utility classes in custom HTML unless you verify they exist on a live page.

Light and dark mode

StatusDashboard toggles a dark class on <html> when a visitor chooses dark mode (or when their saved preference and system setting call for it). Built-in page styles use that class. Your Header and Footer HTML does not pick up those styles automatically.

Define theme-aware rules here by prefixing selectors with .dark. The ancestor class applies to your custom HTML because it sits inside the same document.

Prefer .dark over @media (prefers-color-scheme: dark) alone. A visitor can choose light mode even when their OS prefers dark, and the class reflects that choice.

Example — shared styles for custom header and footer

/* Light mode (default) */
.sd-custom-header,
.sd-custom-footer {
  background: #ffffff;
  color: #0f172a;
}

.sd-custom-header a,
.sd-custom-footer a {
  color: #64748b;
}

/* Dark mode */
.dark .sd-custom-header,
.dark .sd-custom-footer {
  background: #0f172a;
  color: #ffffff;
}

.dark .sd-custom-header a,
.dark .sd-custom-footer a {
  color: #94a3b8;
}

/* Optional: blend the platform action bar with your header */
nav[aria-label="Dashboard status bar"] {
  background-color: #f1f5f9;
}

.dark nav[aria-label="Dashboard status bar"] {
  background-color: #1e293b;
}

Give matching class names in your Header and Footer HTML tabs (see those pages for full markup examples). Inline styles in HTML override stylesheet rules, so move color and background properties into CSS when you need both modes.

External resources

Custom CSS can use @import for Google Fonts (fonts.googleapis.com). Other external stylesheet URLs may be blocked by the status dashboard content security policy. Images referenced from CSS follow the same rules as images in HTML (https: URLs are allowed).

Behavior

Styles are injected when the public dashboard shell loads after status data is available.
Changes take effect when updated custom code arrives from the status API: on the next full page load, or within about 30 seconds for visitors who already have the page open (status data polls in the background).
CSS remains active when visitors move between routes without a full reload.
If you clear all CSS and save, the <style id="sd-custom-css"> tag is removed.
Maximum length: 50,000 characters.

On this page