English

Deutsch

English

Deutsch

Appearance

Customization ​

Beyond the basics, status pages have a range of options to fit how you want to communicate status to your audience. Everything here is configured in the page's settings in the dashboard.

Email Subscribers ​

Let visitors subscribe to updates by email. When you publish an incident or schedule maintenance, subscribers get notified automatically -- they don't have to keep the page open.

  • A Subscribe option appears on the page when you enable it.
  • Subscriptions use double opt-in: visitors confirm their address via a link before any updates are sent.
  • Every notification includes an unsubscribe link, so visitors can opt out at any time.

Feeds ​

Each status page publishes machine-readable feeds, so people can follow updates in a feed reader or wire them into their own tooling:

  • RSS -- /feed.rss
  • Atom -- /feed.atom
  • JSON -- /feed.json

The feeds are served from your status page's address (your subdomain or custom domain).

View Mode ​

Choose how much detail the page shows:

  • Simple -- A clean, at-a-glance view: each monitor's current status and uptime.
  • Extended -- Everything in Simple, plus 24-hour average response times and small response-time sparklines per monitor, so visitors can see performance trends, not just up/down.
  • Modern (overview and history) -- A full status site with two tabs. Overview opens with a summary of the current state, then incident cards (affected service, customer impact, next update, the update timeline), your components grouped with their descriptions and 30 daily bars. Visitors can select a day with the mouse or the arrow keys to see its availability and mean response time, and open a response-time chart and a daily table. History shows a calendar of the last 90 days per component and past incidents and maintenance. It includes a subscribe dialog, planned maintenance and the feeds, and follows your page's light or dark setting.

For the Modern view, set a Website URL in the page's design: the logo and a "Back to website" link point there. Without one, the page shows no such link. On an incident update you can also add the customer impact and the time of the next update; the Modern view shows both on the incident card and hides them when they are empty.

Uptime History & Thresholds ​

  • History window -- Choose how far back the uptime history goes, up to 90 days.
  • Warning and critical uptime thresholds -- Set the uptime percentages at which a monitor is shown as degraded (warning) or in trouble (critical), so the page's color coding matches your own expectations.

Display Options ​

  • Color mode -- Show the page in system, light, or dark mode.
  • Page language -- Set the language the page is shown in.
  • Custom text -- Override the page's wording where you want it to read in your own voice.
  • Per-monitor display name & order -- Give each monitor a friendlier name for the public page and control the order monitors appear in.
  • Upcoming maintenance -- Scheduled maintenance windows are shown on the page as upcoming events, so visitors know what's planned.
  • Branding -- Upload your logo and favicon, and set your brand colors to match your site.

Search Engines ​

Under Domain & Security → Search engines, the Robots meta tag setting decides whether search engines may list your status page in their results:

  • index (visible in search engines) -- the default. Most status pages are meant to be found; customers looking for "is X down" should land on yours rather than a third-party guess.
  • noindex (hidden from search engines) -- the page stays reachable to anyone with the link, but asks search engines to keep it out of their results.

The setting applies the same way on all three addresses a page is served from -- the shared status.hoppla.dev/your-page URL, your your-page.status.hoppla.dev subdomain, and your own custom domain. The directive travels with the page, not with the host.

Why we don't block crawlers in robots.txt

A noindex page is still allowed in robots.txt, on purpose. Disallow stops a search engine from fetching a page, which means it never reads the noindex -- and Google will still list a disallowed URL it found through a link somewhere else, just without a description. Blocking would produce the exact outcome the setting exists to prevent. Instead we serve the directive on the page itself, as a <meta name="robots"> tag and an X-Robots-Tag response header, and leave the page crawlable so it can be read.

A page that isn't publicly reachable -- set to private, or protected by a share token -- is always served noindex regardless of this setting, because there is nothing for a crawler to index.

Removal from search results is not instant: search engines apply it the next time they crawl the page, which can take days.