public system status

Monitors ready before launch.

The status page is populated from the same source-backed inventory used by release gates: app health, public routes, auth, custom domains, jobs, alerting, and incident communication.

monitored components

What the public status page tracks

10 monitors cover app traffic, dependency health, user entry points, background jobs, alerting, and incident communication.

Application liveness

The Next.js application process is running and serving the repo-owned live identity.

Operational

Target: /api/internal/health/live
Cadence: 60 seconds
Expected: HTTP 200 with service=wrxstack and check=live
Impact: Portfolios, auth screens, admin routes, and public APIs can receive traffic.

Dependency health

Database, R2, Anthropic, and SES dependency probes report platform readiness.

Operational

Target: /api/internal/health
Cadence: 2 minutes
Expected: HTTP 200 or explicit degraded JSON with named dependency states
Impact: Generation, uploads, email, and publishing stay observable before users notice drift.

Public portfolios

The public portfolio renderer serves tenant pages and route states.

Operational

Target: /public-site
Cadence: 2 minutes
Expected: HTTP 200 and visible Folio public content
Impact: Visitor-facing home, about, case study, and contact pages continue loading.

Authentication

Signup, login, verification, reset, and settings entry points stay reachable.

Operational

Target: /login
Cadence: 2 minutes
Expected: HTTP 200 with login form content and no framework overlay
Impact: Users can create accounts, sign in, recover access, and manage security settings.

Tenant admin

Authenticated tenant admin entry points redirect or render safely.

Operational

Target: /admin/demo-founder
Cadence: 5 minutes
Expected: HTTP 200/302 guarded response with no 5xx
Impact: Owners and editors can manage content after authentication.

Custom domains

Caddy routes verified domains and the ASK endpoint fails closed for unknown hosts.

External proof

Target: /api/internal/caddy/ask?domain=example.invalid
Cadence: 5 minutes
Expected: HTTP 404 JSON denial for unknown domains; allow only active verified domains
Impact: Connected domains resolve only after ownership, routing, and TLS checks pass.

Media processing jobs

Media cleanup and processing jobs keep uploads moving and remove stale assets.

Operational

Target: portfolio-process-media-assets
Cadence: 10 minutes
Expected: Render cron succeeds and records source-safe counters
Impact: Images, audio, video, and document thumbnails complete processing or retry safely.

Security alerting

Super-admin anomaly detection, alert delivery, audit checksums, and exports run on schedule.

Operational

Target: portfolio-super-admin-alert-delivery
Cadence: 2 minutes plus daily/weekly audit jobs
Expected: Render cron succeeds; alerts remain source-safe and auditable
Impact: Critical admin activity, audit integrity, and offsite evidence remain monitored.

Error tracking

GlitchTip receives unexpected server failures while remaining admin-access gated.

Operational

Target: https://errors.portfolio.wrxstack.com
Cadence: 5 minutes
Expected: HTTP 403 for public clients, allowed only from configured admin sources
Impact: Unexpected errors are captured for triage without exposing the error console publicly.

Status page

Uptime Kuma is routed at the public status domain and populated from this source inventory.

Operational

Target: https://status.portfolio.wrxstack.com
Cadence: Release and incident updates
Expected: Public status page lists all launch-critical components and incident templates
Impact: Users can see component-level status, incident phases, and maintenance messaging.

incident states

Public copy stays ready before the incident.

The copy below is intentionally source-safe: no provider tokens, customer rows, internal screenshots, or raw logs belong on a public status page.

Investigating

within 5 minutes for SEV-1

We are investigating an issue affecting wrxstack. We will share the next update as soon as the affected component is confirmed.

Assign incident owner, capture request IDs, check Render, GlitchTip, Uptime Kuma, health routes, and recent deploys.

Identified

within 15 minutes for SEV-1

We have identified the affected component and are applying a fix or rollback. The next update will include verification status.

Start rollback or mitigation, run focused health checks, and keep customer-facing copy source-safe.

Monitoring

after mitigation is deployed

A mitigation is in place and we are monitoring recovery before marking the incident resolved.

Run health, smoke, API, and affected focused gates before resolving.

Resolved

after verification passes

The issue is resolved. We will publish follow-up notes if customer action is required.

Close the incident, file the postmortem, assign action items, and archive source-safe evidence.