Monitoring

The SCF Controls Platform includes a built-in monitoring dashboard that helps you understand system health, track usage, and monitor compliance progress. This guide covers accessing and interpreting the monitoring features.

Platform health and statistics

Earlier releases had a Database button in the header that opened a Database Health & Statistics popup. That component is no longer wired into the application — nothing renders it, and there is no button to click. The data behind it is still served, so the figures below are all available, but you read them from the API rather than from a screen.

curl -sS -H "X-API-Key: $API_KEY" http://localhost:8000/api/database/stats | jq

Any authenticated session works — an API key or a signed-in user’s bearer token. If you want this as a dashboard, scrape the endpoint into whatever you already use (/api/version and /api/database/catalog-stats alongside it).

What the endpoint returns

GET /api/database/stats responds with:

Section	Information
Version Information	Platform version, API version, catalog version
Health Status	Overall system health (Healthy/Unhealthy)
Database Tables	Record counts for all tables
Control Statistics	Selected, implemented, at-risk counts
User & Task Statistics	Active users, pending/completed/overdue tasks
By Implementation Status	Controls grouped by status
By Maturity Level	Controls grouped by maturity
Tasks By Status/Type	Task breakdown
Recent Activity	Last update timestamps

Key Metrics to Watch

Metric	What It Tells You
Health Status	Overall system health
At Risk Controls	Controls needing attention
Overdue Tasks	Tasks past their due date
Pending Tasks	Work queue size
Active Users	Current user engagement
Total Records	Database size over time

Version Information

The dashboard shows version details useful for support:

Platform: v1.0.0 (API v1.0)
Catalog: SCF 2025.4 (1,451 controls, 300+ evidence requirements)

Health Status

What Health Status Means

Status	Meaning	Action
Healthy	All systems operating normally	None needed
Unhealthy	There’s a problem with the platform	Contact support

When to Check Health

Daily — Quick glance to ensure systems are running
Before critical work — Verify health before bulk operations
When issues occur — First step in troubleshooting

The unauthenticated `/health` endpoint

Separate from /api/database/stats above, the backend serves an unauthenticated GET /health. It is what the container healthcheck and any load balancer in front of the platform poll, so it takes no credentials and answers in a few milliseconds.

curl -s http://localhost:8000/health | jq

{
  "status": "healthy",
  "service": "cg-scf-backend",
  "version": "1.0.0",
  "components": {
    "redis": { "status": "healthy", "redis_version": "7.4.6", "connected_clients": "unknown" },
    "evidence_storage": { "status": "ok", "source": "bundled", "provider": "minio" }
  }
}

The `evidence_storage` component

It reports the platform-wide effective storage — the store an organisation with no configuration of its own falls back to. It says nothing about any individual organisation’s store, which is per-organisation state and not a property of this process.

`status`	`source`	What it means	Does it degrade `/health`?
`ok`	`bundled`	The object store this installer provisioned into the stack	No
`ok`	`platform`	A platform-wide store an operator configured in the app	No
`ok`	`legacy_env`	No platform configuration row; the process environment is in force	No
`unconfigured`	`none`	This installation has no platform store at all. Organisations that have configured their own are unaffected and still work	No — see below
`error`	`none`	The configuration could not be resolved, an undecryptable secret being the case that actually happens. An `error` field carries the exception class name	Yes, the overall status becomes `degraded`

Two deliberate omissions. No bucket, endpoint or credential appears in the response: the endpoint is unauthenticated and reachable by anyone who can reach the port, and a bucket name is an asset inventory. Which kind of store, and whether it resolves, is all this can safely say.

It never dials the store. A round trip per poll would turn a healthcheck into a traffic generator against a customer’s object store — Docker polls this every 30 seconds for the life of the container — and one network blip would flap container health and restart a healthy backend. The answer comes from the resolver’s own cached snapshot. For a real reachability answer, use the administrator-triggered connection test (POST .../evidence-storage/test, see Quick Reference), which dials the store and has somebody to report the failure to.

unconfigured does not degrade the service, and this is the point of it. An installation made with --no-minio is in that state by design and is perfectly healthy; so is one whose organisations have each brought their own store. Marking it degraded would take a working platform out of load balancer rotation for a condition only an administrator can resolve.

Database Statistics

Table Record Counts

The dashboard shows record counts for each table:

Table	Description
Organisations	Number of organisations configured
Scoped Controls	Controls in scope for compliance
Evidence Tracking	Evidence items being tracked
Users	Registered user accounts
Organisation Members	User-organisation associations
Assignments	Control/evidence assignments
Comments	Discussion comments
Evidence Tasks	Evidence collection tasks
Notifications	System notifications
Total Records	Sum across all tables

Understanding Record Counts

Growing steadily — Normal as you add more data
Sudden increase — May indicate bulk import
Sudden decrease — Check if backup was restored
Very high counts — May need data cleanup

Control Statistics

Implementation Breakdown

The dashboard shows controls by implementation status:

Status	What to Monitor
Implemented	Should grow over time
In Progress	Track to ensure progress
At Risk	Investigate and resolve
Not Started	Plan implementation work

Maturity Distribution

Track control maturity levels:

Level	Healthy Distribution
Initial	Should decrease over time
Developing	Common for newer controls
Defined	Target for most controls
Managed	Indicates mature programme
Optimised	Best-in-class controls

Task Statistics

Task Status Overview

Metric	What It Means
Pending Tasks	Work waiting to be started
In Progress	Active work items
Completed	Finished tasks
Overdue	Tasks past due date

Healthy Task Metrics

Overdue: 0-5% — Keep overdue tasks minimal
Pending: < 50% — Most tasks should be in progress or completed
Completed: Growing — Shows progress over time

User Statistics

Active Users

Track user engagement:

Metric	Meaning
Total Users	All registered users
Active Users	Users who have logged in recently

User Activity Indicators

High activity — Good engagement with the platform
Low activity — May need training or outreach
Sudden changes — Investigate cause

AI Evidence Assessment Activity

Window assessments run on the evidence_window Celery queue: on upload and webhook ingest (after a debounce, WINDOW_ASSESSMENT_INGEST_DEBOUNCE_SECONDS), from the nightly sweep at 04:00 UTC, and on request. Three checks tell you the pipeline is alive without reading worker logs:

# Verdicts waiting for a human, worst first (window tier is the primary surface)
curl -sS -H "X-API-Key: $API_KEY" \
  "http://localhost:8000/api/organizations/$ORG_ID/evidence/assessment/review-queue?tier=window" | jq '.total'

# Window status counts — a growing "processing" or "error" count means the worker is not draining the queue
curl -sS -H "X-API-Key: $API_KEY" \
  "http://localhost:8000/api/organizations/$ORG_ID/evidence/window-assessments/summary" | jq

# The flags the backend is actually running with (compare with the frontend's console warning, if any)
curl -sS http://localhost:8000/api/features

Every confirm or override appends a row to evidence_window_assessment_versions (append-only, enforced by a database trigger), so GET …/window-assessments/{id}/versions is the audit trail for a verdict. Both version tables are covered by scripts/backup.sh.

Monitoring Best Practices

Daily Checks

Call GET /api/database/stats and verify "status": "healthy"
Check at-risk and overdue counts
Review any unexpected changes in record counts

Weekly Checks

Review implementation progress trends
Check task completion rates
Review user activity levels
Verify backup is recent

Monthly Checks

Review maturity level distribution
Analyse control implementation velocity
Check data growth trends
Review and archive old data if needed

Performance Indicators

Response Times

Normal performance expectations:

Action	Expected Time
Page load	< 2 seconds
Search results	< 1 second
Save operations	< 2 seconds
Backup download	5-30 seconds depending on data size

If Performance Is Slow

Check your internet connection
Clear browser cache — Hard refresh with Ctrl+Shift+R
Try a different browser — To rule out browser issues
Check platform health — May be a temporary issue
Contact support — If issues persist

Alerting

Built-in Alerts

The platform provides visual indicators for:

Condition	Indicator
At-risk controls	Badge count in dashboard
Overdue tasks	Badge count in tasks section
Sync issues	Status indicator in header

Staying Informed

Check dashboard daily — Review key metrics
Enable email notifications — Get alerts for assignments and due dates
Set calendar reminders — Schedule regular review sessions

Troubleshooting Monitoring Issues

Dashboard Won’t Load

Hard refresh the page (Ctrl+Shift+R)
Check your internet connection
Try signing out and back in
Contact support if issue persists

Statistics Seem Wrong

Click refresh to get latest data
Check if filters are affecting the view
Verify you’re looking at the correct organisation
Contact support if numbers seem incorrect

Health Shows Unhealthy

Note any error messages displayed
Try refreshing the page
Check if other features are working
Contact support with details of the issue

Configuration — Platform settings
Backup & Restore — Data protection
Troubleshooting — Resolving issues