Monitoring Status Page

Monitoring Status Page turns Monitoring sensors into status pages. Each page shows an overall status banner and each component's current state. Below that are a 90-day strip of daily uptime bars and the past week's incidents. Everything runs inside your Drupal site, with no external service or subscription.

Features

• Components from sensors. Group one or more Monitoring sensors under a public name and description. Choose how each Monitoring status (OK, INFO, WARNING, CRITICAL, UNKNOWN) maps to up, degraded, outage or no data. A component takes the worst state of its sensors.
• Status pages at any path. Create as many pages as you need, such as a public /status and an internal one. Each has its own ordered components, number of days (30–365), mobile window and incident history length.
• 90-day uptime bars. There is one bar per day, colored by the worst state that lasted long enough. Hover or keyboard focus shows that day's uptime, degraded and outage
  time, and incidents. Each component gets an uptime summary such as "99.65% uptime over the monitored part of 90 days; degraded on 11 days".
• Automatic incidents. Non-up periods become incidents, and problems separated by a short gap are merged into one. Editors can retitle, annotate or hide incidents, and
  their edits are never overwritten.
• Its own compact history. Each run of one status is stored as a single row per sensor, whatever Monitoring's result-logging setting. Changing a component's sensors or
  mapping recomputes its whole history. Existing Monitoring result logs can be imported.
• HTTP endpoint sensor. Make external services, such as an API or a customer portal, into components. It checks status codes, optional body text and latency. It follows
  same-host redirects only and caps the timeout at 10 seconds.
• summary.json. An optional machine-readable summary per page, shaped like Atlassian Statuspage's, so existing tooling can read it.
• Fast and cache-friendly. Pages are fully cacheable for anonymous visitors and refreshed through cache tags. Responses carry Cache-Control: public, max-age
  for Varnish, Akamai or other CDNs. Purge works without extra code.
• Accessible. The page targets WCAG 2.2 AA, with AA contrast in both the dark and light schemes. Status is never shown by color alone. Each bar strip is one tab stop with
  arrow-key, Home and End navigation.
• Themable. Every color, radius, size and font is a CSS custom property, and the default look is dark with a light variant. Five Twig templates can be overridden per page
  or per component.
• Extensible. Every service can be swapped through its interface. Events fire on component state changes and when incidents open or resolve, ready for a notifications
  add-on.

Post-Installation

1. Give trusted administrators the restricted Administer status pages permission.
2. Optionally add HTTP endpoint sensors at Configuration » System » Monitoring » Sensors.
3. Add components at Configuration » System » Status pages » Components, choosing the sensors and the status mapping for each.
4. Add a status page at Configuration » System » Status pages with a path, its components in order, and whether it is public.
5. Schedule checks every minute: drush monitoring-status-page:run (alias msp-run). The README has examples for crontab, a systemd timer and a Kubernetes CronJob.
   The status report warns if checks stop.
6. Let editors annotate incidents at Reports » Status page incidents. Give them Edit status page incidents and the Status page note text format permission.

To try it out first, enable Monitoring Status Page demo, run drush msp-demo --days=90 and visit /status-demo.

Additional Requirements

• Drupal 10.3 or later, or Drupal 11, on PHP 8.2 or later.
• Monitoring 1.22 or later.
• A scheduler that runs Drush every minute, for minute-resolution history.

Recommended modules/libraries

• Purge, to send cache invalidations to your CDN.
• Monitoring Endpoint, for Uptime Kuma or Nagios. It works alongside this module, and the sensor runs it triggers are
  recorded too.

Similar projects

• Monitoring provides sensors and admin reports but no public status page. This module builds on it rather than replacing it.
• Monitoring Endpoint exposes current sensor states as token-protected JSON for external monitors. It has no history,
  uptime or public page.
• Hosted services such as Atlassian Statuspage provide similar pages outside Drupal. This module keeps the data, the page and the access control in your own site.

Security

Public pages and summary.json show only component names and descriptions, computed states, generated incident text and notes in a restricted text format. Sensor names, messages, URLs and
error text are never shown. The HTTP endpoint sensor can reach internal hosts by design, so changing it requires the restricted administer permission.

Roadmap

Planned after 1.0:

• Email and webhook subscriptions.
• A manual incident workflow (investigating, identified, monitoring).
• Scheduled maintenance windows.
• Aggregating several sites on one page.

The storage is designed so these can be added without migrating existing history.

Community Documentation

See the README for configuration, scheduling, theming with CSS custom properties, and the CDN and Purge setup. Report bugs and suggest features in the href="https://www.drupal.org/project/issues/monitoring_status_page">issue queue.