Skip to main content

How Custom Views Work

Custom views let you publish a scoped version of your status page for a specific audience, team, or customer segment.

Custom views in the live demo

tip

Use a custom view when one audience only cares about a subset of your hierarchy and does not need the full page.

This guide is based on:

  • application/frontend/src/pages/admin/CustomViewsManagement.jsx
  • application/frontend/src/pages/CustomViewPage.jsx
  • application/frontend/src/pages/SubscriberManagementPage.jsx
  • application/backend/cmd/server/routes.go

What a custom view is​

At a high level, a custom view is:

  • a named view
  • tied to selected component IDs
  • accessible by short code
  • optionally given a URL alias
  • optionally protected with an email-based viewer gate
  • manageable by owners and managers

The public page for a custom view is loaded by code, and the current frontend route is:

  • /v/:code

The backend also exposes:

  • GET /views/:code
  • GET /views/:code/data
  • GET /views/:code/viewer-access/status
  • POST /views/:code/viewer-access/request
  • GET /views/:code/viewer-access/consume

Public versus protected custom views​

Custom views now support lightweight audience protection without requiring organization directories or SSO.

Current access modes are:

  • public
  • verified_email
  • allowed_domains
  • allowed_emails

In practice:

  • public behaves like the original scoped link
  • verified_email asks the viewer to confirm an email address before opening the view
  • allowed_domains only grants access to approved email domains
  • allowed_emails only grants access to explicitly approved email addresses

The current v1 design keeps this lightweight on purpose:

  • no org management
  • no user provisioning
  • no SSO dependency
  • no reusable audience objects yet
note

Protected custom views currently assume the parent page itself stays public. The view adds the extra audience gate on top of a public page, rather than replacing full page-level private-page authentication.

What customers see​

The current custom-view page renders a scoped status experience instead of the full page.

From the current frontend implementation, that public experience can include:

  • the custom view name and description
  • monitored component count
  • overall scoped status
  • active incidents relevant to the selected components
  • resolved incidents relevant to the selected components
  • a scoped hierarchy tree
  • share support

It can also surface a warning if components referenced by the view have been deleted or are otherwise unavailable.

How a view is defined​

The admin-side custom-view management flow supports:

  • name
  • description
  • URL alias
  • component selection
  • manager management

From the implementation, admins can:

  • search views
  • open a management modal
  • update the definition
  • change component scope
  • change the viewer access mode
  • maintain approved email or domain lists
  • tune the access prompt and viewer session TTL
  • add and remove managers
  • delete the view

Short code versus alias​

The current product uses a short_code as the durable identifier for a custom view.

The admin UI also supports a friendlier alias.

In practice:

  • the short code is the stable system identifier
  • the alias is the nicer human-facing URL label when you want one

The current product also includes a page-admin View Alias Blocklist screen for reserved aliases that should never be used by custom views.

That means an alias can be rejected even when it looks valid syntactically. Reserved words such as admin paths or unsafe labels should be blocked there rather than discovered accidentally later.

note

If you are documenting or automating around custom views, treat the short code as the safer source of truth.

Terraform follows the same rule. Import and export workflows key custom views by short_code, even when an alias is present for the human-facing URL.

Management and ownership​

Custom views support manager workflows in both page-admin and self-service flows.

The current backend exposes management endpoints for:

  • requesting a magic link
  • validating a management token
  • updating a view
  • deleting a view
  • listing managers
  • adding managers
  • removing managers
  • transferring ownership

That means a custom view is not just a static filter. It is a managed resource with access and ownership workflows.

Self-service management​

The subscriber management workspace also includes custom-view management.

From the current frontend code, a managed custom-view workflow can include:

  • discovering available custom views
  • creating a new custom view
  • editing a selected custom view
  • selecting specific components for the view
  • managing managers

This is what makes custom views useful beyond internal admin teams. They can also be delegated to resource owners and managers through the broader self-service model.

When to use a custom view​

Custom views are a good fit when:

  1. one customer only uses part of your platform
  2. one internal team only needs one service area
  3. you want a stable scoped link instead of telling people to mentally ignore most of the page

Custom views are a weaker fit when:

  1. the audience really needs the full service picture
  2. the scoped component set changes constantly
  3. a single alias would create more confusion than clarity

Custom views versus the main public page​

Use the main public page when you want:

  • a broad service picture
  • all major incidents and maintenance in one place
  • the full hierarchy

Use a custom view when you want:

  • narrower audience scope
  • fewer components
  • only the incidents relevant to that audience
A simple way to think about it

The main status page answers “what is happening across our service.” A custom view answers “what is happening in the part of the service that matters to you.”