Support Readiness

Applies to: All subscriptions

Purpose

Say, before a customer goes live, whether the things support depends on are really in place. Each of them used to fail silently: a blank alert recipient list looks exactly like "no alerts needed", and a recipient left over from a template emails a stranger.

Three facts decide how to read it:

1. It reports; it never fixes and never sends. It reads configuration and says what is missing. It changes nothing and sends no mail.
2. A missing business decision is not a pass. If nobody has written down support hours, response targets and an escalation route, the check says NOT_SUPPLIED, every time it runs, until someone does. It never invents plausible numbers.
3. It never shows a secret. An email address is shown with the start of the name hidden (s***@example.org); a connection string is never shown, only that one is set.

Audience

Whoever deploys Complifly, and Complifly's own support and platform engineers.

Prerequisites

• A Complifly staff role that holds observability.platform (Super Admin, Support Engineer, Platform Engineer) for the API. A customer's administrator receives 403.
• For a self-hosted deployment, access to the server's environment variables. See Environment Variables.

Reference

Where it appears

Place	What you see
GET /api/admin/observability/support-readiness	The full result as JSON
Admin & Logs > Observability (Security health panel)	The dependency-audit result, including when it could not run
The server's start-up log	One summary line, then one line per check that is not PASS. In production a FAIL is logged as an error and a WARN as a warning; elsewhere everything is information, because a developer's machine legitimately has no alert recipients
The deployment pre-flight (scripts/preflight_commercial_stack.js, support area)	The same checks before the deploy proceeds. Advisory, except in production

The result

{
  "ready": false,
  "summary": { "pass": 5, "warn": 2, "fail": 0, "notSupplied": 1 },
  "checks": [
    { "id": "SUPPORT_MATRIX", "area": "support", "status": "NOT_SUPPLIED", "summary": "…", "action": "…" }
  ]
}

ready is false when any check is FAIL. WARN and NOT_SUPPLIED do not change it, but they are always listed: they are the open items.

Status	Meaning
PASS	In place
WARN	Works, but a person should look
FAIL	Support cannot do this job as configured
NOT_SUPPLIED	A business input nobody has provided yet. Never PASS, never guessed

The checks

Check id	Area	FAIL or WARN when	Fixed by
ALERT_RECIPIENTS_P1	alerts	FAIL: no one receives P1 alerts, or a recipient is malformed or a placeholder (example.com, test, changeme, tbd …). A P1 condition would be raised and nobody told	Set PLATFORM_ALERT_RECIPIENTS_P1 (or PLATFORM_ALERT_RECIPIENTS) to the support mailbox or on-call address
ALERT_RECIPIENTS_P2	alerts	WARN for none, FAIL for a placeholder	Set PLATFORM_ALERT_RECIPIENTS_P2 (or PLATFORM_ALERT_RECIPIENTS)
ALERT_MAIL	alerts	FAIL: outbound mail is not configured or the sender address is missing or malformed. No alert email, sign-in code or password reset can be sent	Set the Azure Communication Services connection string and a verified sender address
HEALTH_SWEEP	alerts	FAIL: the sweep is off. No platform alert is ever raised, whoever is on the recipient list	PLATFORM_HEALTH_SWEEP_ENABLED=true
ERROR_TRACKING	observability	WARN: no error tracker is configured, so an unhandled exception is written to the log and nowhere else	Set SENTRY_DSN, or accept that exceptions are found by reading logs
SUPPORT_MATRIX	support	NOT_SUPPLIED until tiers, hours, first-response targets, an escalation route, a commercial contact and an out-of-hours contact are all written down; while only some are, it still says NOT_SUPPLIED but lists what is recorded and what is missing. FAIL if marked supplied but incomplete	Fill in the support matrix (below)
CAPACITY_ALERTS	support	WARN: the scheduled capacity-alert run is on (COMMERCIAL_CAPACITY_ALERTS_ENABLED=true) but the support matrix has no usable commercial contact, so limit crossings are recorded in each customer's commercial history and nobody is emailed. Not shown at all while the run is off	Supply the support matrix with a commercial contact that is a real mailbox
PROMOTION_SWEEP	support	WARN: the voucher expiry follow-up is on (COMMERCIAL_PROMOTION_SWEEP_ENABLED=true) but the support matrix has no usable commercial contact, so each voucher-funded free period that ends without being converted is flagged on the Commercial tab and recorded in the customer's commercial history, and nobody is emailed. Not shown at all while the follow-up is off	Supply the support matrix with a commercial contact that is a real mailbox
POLICY_GATE	policy	WARN: the API-policy or tenant-lifecycle gate let requests through without applying its control since the process started. They fail open by design, so nothing was blocked	Query platform_event_log for EventType = 'POLICY_GATE_DEGRADED' (Important tier; the Observability tab lists Critical events only, so it is not shown there). Each row says which gate and why
PLAN_ASSIGNMENTS	policy	WARN: an API key or integration client names a plan the system cannot find, so it has no quota and no registration cap	Correct the credential's plan code; see Integration Policies
SECURITY_REPORT	security	WARN: no dependency audit has been recorded, it is more than 7 days old, it could not run (the picture is unknown, not zero), or it found a critical vulnerability	Enable SECURITY_REPORT_ENABLED; see the Security health panel

The support matrix

The support matrix is a short file (config/support/supportMatrix.js) that records only what the business has decided. Support tiers, hours and response targets are a commitment the business makes, so a field nobody has decided stays empty rather than being filled with a plausible number that would read as a promise.

What has been decided (decision D-7, 2026-10-24): support hours are 10:30 to 18:00 IST, and the support tier follows the plan: Starter Standard SLA, Growth Priority SLA, Enterprise Enhanced SLA, Custom a Custom SLA. The matrix is therefore marked PARTIAL. It does not yet hold a first-response target or an escalation route for any tier, nor the two contacts.

When the business has decided the rest, the file records, for each tier, a name, hours, a first-response target and an escalation route, plus two contacts: who hears when a customer approaches or passes a plan limit, and who can be reached out of hours. Status SUPPLIED then asks the check to verify that nothing is half-filled. Contacts are read only from a SUPPLIED matrix, so a PARTIAL one emails nobody.

Nothing in the product enforces these targets. The matrix makes what support and the customer have agreed visible; it is not a service-level mechanism. This is assumption D3 in the Assumptions Register.

Validation

Check	Method	Pass condition
The check runs	GET /api/admin/observability/support-readiness as a staff user	200 with a checks array
A customer cannot read it	Call it as a customer's Organisation Admin	403
A blank recipient list is caught	Clear PLATFORM_ALERT_RECIPIENTS_P1 and PLATFORM_ALERT_RECIPIENTS, restart	ALERT_RECIPIENTS_P1 is FAIL and ready is false
A placeholder is caught	Set a recipient at example.com	FAIL, with the address shown masked
No address leaks	Read the whole response	No full email address and no connection string appears

Troubleshooting

Symptom	Cause	Action
ready is true but SUPPORT_MATRIX is NOT_SUPPLIED	Expected. NOT_SUPPLIED is an open item, not a failure	Obtain the support commitment from the business and record it
HEALTH_SWEEP is FAIL on a development machine	The sweep is off by default	Expected in development; set it on in any environment that serves a customer
POLICY_GATE stays WARN after you fixed the cause	The count is per process and resets on restart. In a deployment with more than one process, each reports its own	Restart the process, or watch the event stop
POLICY_GATE is PASS but you suspect a degradation	The count is held in memory and starts at zero on every restart; the check run by the deploy pre-flight is a fresh process and always sees none	Query the event log for POLICY_GATE_DEGRADED
Recipient shown as a***@…	The local part is masked deliberately	None
SECURITY_REPORT says unknown	The audit could not run (no network, no lock file)	See the Security health panel for the reason per side; an unknown result is never reported as clean

Related Articles

• Alerting
• Logs and Observability
• Health Endpoints
• Environment Variables
• Administration API
• Assumptions Register