status-page

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The public GitHub repository holds every interim change, not just releases: work lands on dev through reviewed pull requests, is promoted to stage (a live preview at stage.status.szolotov.com) and then to main, where releases are tagged. Each commit between releases is visible and reviewable. https://github.com/greenblacked/status-page/commits and https://github.com/greenblacked/status-page/pulls?q=is%3Apr

Repository on GitHub, which uses git. git is distributed.

Each release has a unique version number (v0.1.0 through v0.5.0 so far). release.yml derives it from the Conventional Commits since the last tag, sets it in package.json, tags it and publishes a GitHub Release. The running Worker reports its version in the X-Worker-Version header. https://github.com/greenblacked/status-page/releases

Every release is identified by a git tag (v0.1.0, v0.1.1, v0.2.0, v0.3.0, v0.4.0, v0.5.0), created by the release workflow on main. https://github.com/greenblacked/status-page/tags

Non-trivial release notes file in repository: https://github.com/greenblacked/status-page/blob/main/CHANGELOG.md.

No publicly known vulnerability (CVE or similar) has ever been reported against this project's own code, so no release has fixed one. Release notes (CHANGELOG.md and GitHub Releases) include a Security section when security-relevant changes ship (for example, the security headers in 0.5.0). Dependency advisories are handled by Dependabot and dependency review.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/greenblacked/status-page/blob/main/SECURITY.md. [osps_do_02_01]

GitHub Issues is the issue tracker, with forms for a bug, a card showing the wrong status, and a new-service request. https://github.com/greenblacked/status-page/issues

No bug reports have been submitted yet (the project's first release was on 2026-09-24), so there are none left unacknowledged. Reports are filed through GitHub Issues and answered by the maintainer. https://github.com/greenblacked/status-page/issues?q=is%3Aissue

No enhancement requests have been submitted yet; new-service requests have their own issue form and are answered in the issue. https://github.com/greenblacked/status-page/issues?q=is%3Aissue

All bug reports, feature requests, and their responses are kept publicly in GitHub Issues, and code review happens publicly in pull requests. Both are permanently archived and searchable (open and closed): https://github.com/greenblacked/status-page/issues?q=is%3Aissue and https://github.com/greenblacked/status-page/pulls?q=is%3Apr

The process is published in SECURITY.md, linked from the README's Security section and shown on the repository's Security tab. Vulnerabilities are reported privately through GitHub's "Report a vulnerability" form. The page explains what to include (affected file or route, reproduction steps, impact), what is in and out of scope, the expected acknowledgement time, and that fixes land on main with credit in the advisory. https://github.com/greenblacked/status-page/blob/main/SECURITY.md

Private reports are supported through GitHub private vulnerability reporting. SECURITY.md links straight to the form (Security tab → Advisories → Report a vulnerability). A report there is visible only to the reporter and the maintainer, is discussed in a private draft advisory, and becomes public only when the advisory is published after a fix. SECURITY.md asks reporters not to use public issues, pull requests or discussions. https://github.com/greenblacked/status-page/blob/main/SECURITY.md and https://github.com/greenblacked/status-page/security/advisories/new

No vulnerability reports have been received in the last 6 months; the project's first release was on 2026-09-24. SECURITY.md commits to acknowledging a private report within a few days, well inside 14 days. https://github.com/greenblacked/status-page/blob/main/SECURITY.md

The board is TypeScript and React compiled by Vite, and the build is fully automated from source: npm ci installs the locked dependencies, npm run build builds the Node server and client, and npm run build:cf builds the Cloudflare Worker (DEPLOY_TARGET=cloudflare). docker compose up preview builds and serves it with no local Node. CI rebuilds on every pull request and push, on the pinned Node and on Node 24, and smoke-tests the built output. https://github.com/greenblacked/status-page#quick-start and https://github.com/greenblacked/status-page/blob/main/package.json

The build uses standard, widely used JavaScript tooling: npm (lockfile-pinned install with npm ci), Vite for bundling, the TypeScript compiler for type checking, Vitest and Playwright for tests, and Biome for lint and formatting. Wrangler builds and deploys the Cloudflare Worker, and Docker Compose offers a no-Node alternative. https://github.com/greenblacked/status-page/blob/main/package.json

Every tool needed to build the software is FLOSS: Node.js (MIT), npm (Artistic-2.0), Vite (MIT), TypeScript (Apache-2.0), React (MIT), TanStack Start (MIT), Tailwind CSS (MIT), and Wrangler for the Cloudflare Worker build (MIT OR Apache-2.0). The Node build (npm ci && npm run build) runs on any Node host with no proprietary tools; only deploying to Cloudflare (a hosting service) uses a Cloudflare account, and that step is optional. https://github.com/greenblacked/status-page/blob/main/package.json

The project has automated test suites, released as FLOSS (MIT) in the repository:

• unit tests with Vitest, with coverage gates (npm test, npm run test:coverage);
• browser tests with Playwright and axe accessibility checks, run in Chromium and WebKit on desktop, iPhone and iPad (npm run test:e2e);
• a smoke test of the built server (scripts/ci/smoke.sh).
  How to run them is documented in the README's Development and Quality gates sections and in CONTRIBUTING.md. CI runs all of them on every pull request and push: https://github.com/greenblacked/status-page/blob/main/.github/workflows/ci.yml
  https://github.com/greenblacked/status-page#development

The tests run with the standard npm commands for a Node.js project: npm test (the Vitest unit suite), npm run test:coverage (the same with coverage gates), npm run test:e2e (the Playwright browser suite), and npm run check (lint, typecheck, unit tests and repository checks in one go). They are defined in package.json and used the same way in CI. https://github.com/greenblacked/status-page/blob/main/package.json

The test suites cover most of the code and functionality.

• Unit tests (Vitest) cover about 68% of lines and 73% of branches, with CI coverage gates (lines 64, statements 63, branches 58, functions 60) so coverage cannot drop.
• They exercise every vendor collector against real trimmed payloads, including a malformed payload for each that must read as unknown.
• Browser tests (Playwright, around 670 across desktop, mobile, iPhone and iPad) cover every user-facing input: search, filters, the URL parameters, keyboard shortcuts, Settings, stars and alerts. They also cover the API routes and accessibility (axe WCAG checks and text contrast).
  https://github.com/greenblacked/status-page/blob/main/vitest.config.ts and https://github.com/greenblacked/status-page/tree/main/e2e

GitHub Actions runs CI on every pull request into dev, stage and main and on every push to those branches: lint, typecheck, unit tests with coverage gates, builds on two Node versions with a smoke test, browser and accessibility tests in Chromium and WebKit, commit and branch checks, and workflow lint. A single required check, "CI OK", passes only when every job does. Changes are merged frequently through small pull requests into dev and promoted to stage and main. CodeQL and dependency review also run on every pull request. https://github.com/greenblacked/status-page/actions/workflows/ci.yml

New functionality must come with tests. CONTRIBUTING.md sets the rules:

• Coverage has minimum thresholds in vitest.config.ts, set just under the current numbers, so CI fails when new code lowers coverage; when coverage rises, the thresholds are raised in the same pull request.
• A new service must add a collector test against a trimmed real payload and a malformed one that must read as unknown.
• UI changes are covered by the Playwright and axe browser tests.
  CI blocks merging until all of these pass.
  https://github.com/greenblacked/status-page/blob/main/CONTRIBUTING.md#ci and https://github.com/greenblacked/status-page/blob/main/CONTRIBUTING.md#adding-a-service

Recent major changes each added tests in the same pull request:

• #55, the board redesign: unit tests grew from 739 to 913. It added new unit tests for the verdict sentence, local time, the background setting, the status glyphs and the search dock geometry, and new browser tests for the phone search dock, 44pt touch targets, the uptime strip on rows, blocked notifications and the 404 page.
• #53, status mapping, feed and alert fixes: added tests for the severity order, AWS regions, Statuspage notices, stable feed ids, alert debouncing and the npm pin scripts, and raised coverage back above the CI gates.
• Every change is merged only when CI OK passes, including the coverage thresholds, which cannot drop.
  https://github.com/greenblacked/status-page/pull/55 and https://github.com/greenblacked/status-page/pull/53

The instructions for change proposals document the testing rules. CONTRIBUTING.md requires npm run check (including the unit tests) to pass before a pull request, sets coverage thresholds that CI enforces and that must be raised when coverage grows, and requires every new service to add collector tests against real and malformed payloads. In practice tests are added with each major change (#53 and #55 each added dozens). https://github.com/greenblacked/status-page/blob/main/CONTRIBUTING.md#ci and https://github.com/greenblacked/status-page/blob/main/CONTRIBUTING.md#adding-a-service

Two FLOSS tools check the code, and CI enforces both on every pull request:

• TypeScript runs in strict mode (tsconfig.json: "strict": true, plus noUnusedLocals and noUnusedParameters), and npm run typecheck fails the build on any type error or unused code. TypeScript also emits ES modules, which are always in JavaScript strict mode.
• Biome (MIT) lints with its recommended rule set plus an extra accessibility rule, formats the code and sorts imports; biome ci fails on any finding.
  CI also runs actionlint and zizmor on the GitHub Actions workflows, shellcheck on the shell scripts, and CodeQL static analysis.
  https://github.com/greenblacked/status-page/blob/main/tsconfig.json and https://github.com/greenblacked/status-page/blob/main/biome.json

The project has zero outstanding warnings: CI treats every TypeScript error, unused local or parameter, and Biome lint finding as a failure, so nothing merges with a warning. biome ci . and tsc --noEmit both report none on the current code. The few intentional exceptions are marked in the source as false positives with a biome-ignore comment that must state the reason (a CONTRIBUTING.md rule). CodeQL alerts are fixed or dismissed with a reason. https://github.com/greenblacked/status-page/blob/main/CONTRIBUTING.md#code-style

Warnings are as strict as practical, and every one fails CI rather than being reported and ignored:

• TypeScript runs in "strict" mode plus noUnusedLocals and noUnusedParameters, and any is banned by project rule.
• Biome runs its full recommended rule set, with an extra accessibility rule raised to error, in biome ci mode.
• Beyond the code, CI lints the shell scripts (shellcheck), the GitHub Actions workflows (actionlint and zizmor), and design tokens (scripts/ci/tokens.sh); runs CodeQL; and enforces accessibility (axe WCAG 2.2 AA and a 4.5:1 text contrast check) in the browser tests.
  Exceptions need an inline biome-ignore with a stated reason.
  https://github.com/greenblacked/status-page/blob/main/tsconfig.json and https://github.com/greenblacked/status-page/blob/main/biome.json

The primary (sole) developer is a DevOps engineer who works with security and infrastructure day to day, and the project's design applies these principles:

• Economy of mechanism: one small Worker, read-only, with no database, accounts or user data; every vendor is read through one collector pattern.
• Fail-safe defaults: an unreadable or malformed vendor payload reads as "No data", never as "up". Strict security headers are on by default: a CSP allowing only the board's own origin, HSTS, nosniff, no framing.
• Complete mediation: every response passes through the same security-header layer, and the deploy token is reachable only by the deploy, preview and rollback steps.
• Open design: all code, CI and deploy logic are public; security rests on the Cloudflare token kept in a protected GitHub environment, not on secrecy of design.
• Separation of privilege: deploys need a protected branch and a separate GitHub environment secret, and main takes changes only by pull request with required checks.
• Least privilege: workflows default to read-only tokens; the token-holding job installs with --ignore-scripts, verifies npm signatures, and runs no project code; pull requests never see credentials.
• Least common mechanism: each request is served from per-isolate state, with nothing shared between users and no user-writable storage.
• Psychological acceptability: plain-language states, keyboard shortcuts, accessibility tests, and settings that respect Reduce Motion and Increase Contrast.
• Limited attack surface: GET-only public endpoints, no user input beyond search and filter parameters, and no uploads or logins.
• Input validation with allowlists: vendor payloads are parsed into a fixed set of states; the badge endpoint accepts only known service ids; URL filters accept only known categories.
  https://github.com/greenblacked/status-page/blob/main/SECURITY.md

The primary developer knows the common vulnerability classes for a web app and its CI/CD pipeline, and the project counters each:

• XSS / injection: React escapes all rendered text; vendor payloads are parsed into typed data, never injected as HTML; a strict Content-Security-Policy (own origin only) is sent on every response.
• Untrusted input: vendor feeds are treated as hostile: parsed with fixed schemas and time limits, and a malformed payload reads as "No data" (tested for every collector). URL parameters and badge ids are checked against allowlists.
• Clickjacking and transport: frame-ancestors none, HSTS, nosniff, and a strict referrer policy.
• Missing authentication/authorization: there is no login and no write endpoint, so the public surface is read-only GET.
• Supply-chain and CI attacks: GitHub Actions and npm are pinned by hash; npm registry signatures are verified; workflows run with read-only tokens; pull request code never runs with secrets; the release job is hardened against cache poisoning and untrusted checkout. zizmor, CodeQL, dependency review, Trivy and OpenSSF Scorecard run in CI.
• Secret exposure: the only secret (the Cloudflare deploy token) lives in a protected GitHub environment and is visible only to the deploy, preview and rollback steps.
  https://github.com/greenblacked/status-page/blob/main/SECURITY.md