STRAXDocs strax.pro

Monitoring

One monitoring area shows the health of every connection, movement, workflow and portal, with searchable logs and enough context to act on any problem.

Two questions, answered on one page

An integration platform must answer two questions at any moment: is everything running, and is data actually moving. The two are different, because a platform can be perfectly healthy while nothing flows. STRAX answers both on a single monitoring overview, with one clear verdict of healthy, warning or critical shown across the whole console.

From that overview, each area of the platform has its own status: every connected system, every data movement, workflow runs, published portals and background activity. A problem in any area surfaces as a card you can open, and each card links directly to the detail that explains it. Triage takes seconds because nobody has to remember where to look.

Problems arrive with context

A red light on its own is close to useless. STRAX surfaces problems with enough context to act on them: which connection failed, which record was affected, what the source system actually said, and when it last worked. An operator sees the difference between a wrong password, an unreachable server and a record the target refused, because the platform reports the actual cause rather than a generic failure.

For Demo ISP, that means the difference between "something is wrong with billing" and "the Splynx connection has been failing authentication since 09:12". The first starts an investigation. The second starts a fix.

Work that recovers itself

Servers restart, databases fill up and networks drop. What matters is what happens to the work that was in flight. STRAX never leaves it hanging: work in progress is held on a short, renewable claim, and when the process holding it stops, the platform closes the item within minutes, records what happened and says how far it got. Work that had not started is simply picked up again. Work that had started is not repeated blindly, because a second run could send a second e-mail or take a second payment; the operator sees exactly which step was reached and re-runs it with one click once it is safe. Workflows that are safe to repeat, such as polls and syncs, can be marked to restart on their own.

The same holds for data movement. A temporary failure is retried until it succeeds, while a record the target genuinely refuses is set aside with its reason, so one bad record never stops the rest. Schedules that keep being skipped, services that have paused, and anything still stuck appear on a dedicated reliability page and are e-mailed to the administrators, so an outage leaves a clear account rather than a silent gap. Each connected system's clock is also checked against the hub's, and administrators are alerted when one drifts out of step, so a wrongly set server clock is caught before it can affect your data.

Complete, searchable logs

Everything the platform does is logged, and the logs are searchable from the console. Support staff can trace a single customer record from the moment it arrived from HubSpot to the moment it appeared on a portal page. Auditors can see who changed what and when. Nobody needs access to servers or files to answer an operational question.

Live figures on the overview show work in progress and anything waiting, so a slowdown is visible as a trend before it becomes an incident. The monitoring pages refresh themselves, making the overview suitable for a wall display in an operations room.

Why this matters

Hand-built integrations tend to fail silently. A script stops, nobody notices, and the gap is discovered weeks later when a report looks wrong. STRAX is built on the opposite assumption: the platform watches itself, and silence is never the failure mode. Data either moves and is seen to move, or stops and is seen to stop.

That visibility also changes conversations with vendors and partners. When a SaaS platform's API misbehaves, STRAX holds the evidence, including exactly what was sent and received through real-time integrations.

Monitoring covers every environment, so a change tested in staging is verified with the same tools it will be watched with in production. For the platform as a whole, start with What is STRAX?.