Health checks

Three screens answer the question. Their permissions differ deliberately: the first is open to anyone signed in, the other two are not.

Screen	Who may open it	Answers
Support center → System information	Any signed-in user	Version, server time, uptime, and two lights: application data and server inventory
Settings → Environment configuration (env.) → Integration status	System settings (settings.system)	Whether each connection is configured, and whether it answers right now
Settings → Integrations and connections → Configured connections	Integrations and connections (settings.integrations)	A real test against one connection, with the time and verdict stored

System information

A panel in the support center, open to any signed-in user: system version, server time, server uptime, how many connections are configured out of the total, the signed-in user, their role and how many permissions they hold.

The two lights that matter are database and server inventory, and they are separate because they fail separately. They also state the consequence rather than the state alone: "unavailable — the servers page is showing demo data" is a sentence you can pass on, where "unavailable" on its own needs one more question. "The calendar works but the servers page shows demo data" is the most common situation this panel exists to explain.

Copy report copies the whole block as text, together with the user, their role, their permission count, the address they were on and the browser.

Integration status

A panel at the top of the environment configuration screen, five rows, with a refresh button that re-runs the checks:

Row	What is checked
Database (MSSQL)	A fast reachability probe — the same one every data read goes through
Active Directory	A real bind result against the directory
Mail server (SMTP)	Whether the server accepts a connection
Request service	Whether it is configured. It is not polled — it is exercised when a ticket is opened
SMS gateway	Whether the channel is enabled

The color carries three states: green — answering now; red — not answering, or disabled; amber — configured, but only verified in use.

Testing one connection

Every configured connection is a card with an enable toggle and a Test button. The verdict is stored and shown beside the name — "OK · 2 hours ago", "Failed · the reason", or "Not yet tested". The failure text is a sentence with the technical error appended verbatim, so it can be handed to the team that owns the other system without translation.

Every test is time-bounded (about eight seconds). A wedged endpoint returns a timeout verdict rather than a screen that hangs.

The mail connection carries a second action beside the test — Send a test email, with a recipient. It exists because a connection that opens successfully is not proof that a message reaches a mailbox; only an email that arrived is.

What actually went out

The two areas that send on their own each keep a log, and in both a row is one attempt:

• Settings → Scheduled reports → Delivery log — time, report, format, result, recipients, size and duration.
• Settings → Alert rules and delivery → Delivery log — the same idea, per dispatch of a rule.

Real runs and tests carry a "Test" badge and never mix. Size and duration are there on purpose: "the file was zero bytes" and "the render took forty seconds" are two different faults with exactly the same symptom — an email that did not arrive.

With no database the log is empty and says so, rather than reading as though nothing was ever sent.

Behavior when a data source is unavailable is described in Architecture. Going from a symptom to a screen is in Troubleshooting.