Skip to content

Monitoring and Health Checks

Applies to: All subscriptions

Purpose

Give the customer's operations team everything needed to configure their own monitoring platform against Complifly, so that a degradation is discovered by an alert rather than by a user.

Audience

Operations and infrastructure teams. Also the customer's integration owner, for the integration signals.

Prerequisites

  • Installation Guide complete
  • The system carrying real traffic, so baselines can be measured rather than guessed
  • A monitoring platform in place

Steps

Page Covers
Health Endpoints Probes, what each proves, and what they deliberately do not
Logs and Observability Log structure, collection, retention, and tracing a request
Key Metrics and Thresholds What to measure and what healthy looks like
Alerting What deserves an alert, who receives it, and how to avoid fatigue

The principle that shapes this section

Complifly fails silently in several places. Monitoring is not a nicety here; it is the mechanism by which several classes of failure become visible at all.

Silent failure What you see without monitoring What to monitor
Queue unreachable An entirely healthy system where uploads never complete Queue depth and job completion, not just process liveness
An integration stopped sending A quiet business day, indistinguishable from a real one Documents received per period, alerted at zero
Write-back consumer stopped Nothing at all Age of the oldest pending event
A document sitting unregistered Nothing, until the reporting window closes Age of documents awaiting registration
Tenant scope wrong in a script An empty report that looks like an empty month Row counts cross-checked against storage metadata

The last three carry deadlines or compliance consequences. They are the reason this section exists.

Monitor from both sides

Complifly cannot tell the difference between an ERP that has stopped sending and a quiet Tuesday. The customer's monitoring must cover the ERP side too: documents sent, rejections handled, write-back events consumed.

An integration that stops silently is the single worst outcome in this product, because the documents are still accruing statutory deadlines while nothing appears to be wrong.

The documentation surfaces are also a dependency

Two of the surfaces a customer relies on are not the application, and both fail silently from the application's point of view:

Surface Why its availability matters What breaks when it is down
The in-product Help Centre Deliberately outside the authenticated route, so it is reachable precisely when a user is locked out A blocked user has no self-service answer, and calls support instead
This portal The reference an administrator uses mid-incident Diagnosis stalls at the moment it is most expensive

Both should be monitored the way any other public endpoint is — an HTTP check against the front page and one deep page, from outside your network — and both should appear on the status page alongside the application. A reader who cannot reach the documentation during an incident and finds the status page silent about it concludes the documentation is fine and their network is broken.

Verify: status.complifly.tech is configured in the domain map and is not yet populated with any component, so there is currently nowhere for a documentation outage to be published. G5

Four layers to cover

Layer Examples
Infrastructure CPU, memory, disk, network
Application Process liveness, response time, error rate
Business Documents processed, rejection rate, unregistered ages
Integration Documents received, write-back backlog, delivery failures

Most teams cover the first two well and the last two not at all. The third and fourth are where the consequences live.

Validation

Monitoring is adequate when the answer to each of these is yes:

Question Why it matters
Would we know within an hour if the application stopped? Baseline
Would we know if uploads stopped completing but the application stayed up? The queue failure is silent
Would we know if an ERP stopped sending documents? Only the ERP side can tell you
Would we know if the write-back consumer stopped? Backlog age, not count
Would we know if documents were approaching the reporting window unregistered? There is no remedy after it closes
Would we know if the provider connection was failing? Generation stops while everything else looks fine
Would we know before a certificate expired? Expiry takes the site down without warning
Would we know before a disk filled? Compliance evidence accumulates continuously
Does someone actually receive each alert? An alert to a departed employee is no alert
Have alerts been tested by firing them? Configured is not the same as working

Troubleshooting

Symptom Cause Action
Users report problems before monitoring does Only infrastructure is monitored Add the business and integration layers
Health probe green while users are blocked The probe is shallow by design See Health Endpoints
Alerts ignored Too many, or too many false positives Tune thresholds against measured baselines
An alert fires and nobody acts No owner, or addressed to an individual Assign owners; use distribution lists
A problem is found only at month end No business-layer monitoring Add the document-age and rejection-rate signals
Thresholds guessed and constantly wrong Set before baselines were measured Measure for four weeks, then set thresholds