Client Channel-Connection Health Diagnostic Automation: The Question Nobody Could Answer From One Place
Two tables, each individually correct, that nobody had ever joined into one answer
A connection-status record and a publish-history table can each be entirely accurate on their own terms and still fail to answer the one question a client actually asks: is this working right now. The connection record knows whether a token exists and when it last synced; the publish history knows whether real posts actually went out or failed. Neither one, alone, tells the full story — and until something reads both together, answering "is my connection okay" requires someone to manually cross-reference two different screens, or simply guess.
How the underlying problem shows up before you fix it
A client asks a direct, reasonable question about their own account, and the honest answer requires cross-referencing two separate tables that nothing in the product already joins.
A connection record can show "active" and "synced today" while the actual publish attempts underneath it have been silently failing — sync success and publish success are two different facts, and a status field checking only the first can look fine while the second is broken.
Two different staff members, asked the same client question independently, cannot answer it either — a sign the gap is in the tooling itself, not in any one person's knowledge.
A support or account-management role has read access to raw connection records that include authentication tokens, when the actual question being asked never required seeing the token at all.
A diagnostic tool returns rich, deeply nested data per record, and at real client-count scale the combined response size grows past what a chat interface can usefully display in one turn.
How the blind spot was found, and how the diagnostic tool closes it without ever exposing a token
The triggering incident was specific: a client asked whether their Instagram connection was still correctly configured after going through a reauthentication flow. The connection record itself showed a healthy status and a same-day sync — genuinely accurate information — but that record alone cannot confirm whether the connection actually WORKS, because syncing metadata and successfully publishing content are two distinct operations. The real proof that an integration works is that content scheduled through it actually goes out, which lived entirely in a separate scheduled-posts table the connection-status view never touched.
The first version of the new tool returned one structured record per client-channel pair: the connection's status and active flag, when it last synced, whether an access token or long-lived token is present (reported only as "present" or "absent" — the actual token value is never read into the response), and two counts pulled from the last 14 days of that channel's scheduled posts — how many published successfully and how many failed — plus, when there was at least one failure, the date and a truncated excerpt of the most recent error message.
A second pass, shipped the same day once the tool was checked against real client volume, rewrote the output from one JSON object per connection into a single compact text line per connection — client name, channel, account, status, active/inactive, last-sync time, token presence, and the 14-day publish scoreboard all on one line — because the object-per-record version produced roughly 12,000 characters for just thirteen real clients, well past what the chat interface reliably displays in one response. The tool's own guidance is direct about what the result means: a connection that is active, recently synced, AND has real posts going out in the same window is, in the tool's own stated words, as strong a test as exists that the integration is genuinely working — and a recent failure surfaces its actual cause directly in the same line, rather than requiring a second lookup.
What is actually built today
A single tool call returns every client-channel connection in the organization: status, active/inactive, last-sync time, and whether a token is present — never the token value itself.
The same call returns a 14-day publish scoreboard per connection: posts that published successfully and posts that failed, computed from the actual scheduled-post outcomes, not from the connection record alone.
A recent failure surfaces its date and a truncated excerpt of the real error message directly alongside the connection it belongs to.
Output is formatted as one compact line per connection rather than a nested object per record, after the first version was found to produce roughly 12,000 characters for just thirteen real clients.
The tool's own guidance states its read explicitly: active, recently synced, and publishing successfully in the same window is treated as the strongest available evidence that a connection genuinely works.
No argument is required to call it — it returns every client the requesting organization has, to be scanned by name rather than looked up one at a time.
The question two people could not answer alone (illustrative framing of the actual measured finding)
A client reauthenticates their Instagram account and asks whether everything still works. Before the fix, answering that honestly means manually opening the connection record to check sync status, then separately opening the post-scheduling history to check whether anything has actually gone out since — two screens, no single answer. After the fix, one tool call returns both facts together for that exact client and channel: connection active, synced this morning, six posts published and zero failed in the last 14 days — a complete, one-line answer to the exact question that was asked.
What changes operationally
Any team member or AI agent can now answer a client's channel-connection question from a single tool call, with the actual publish outcomes — not just sync metadata — as the basis for the answer, closing a gap where two separate staff members had no way to answer the identical real question.
When this is not the right fit
This diagnostic reports connection and publish health — it does not repair a broken connection, reauthenticate an account, or retry a failed post on its own; a person still takes that action once the diagnosis names the problem.
Two correct tables vs. one honest answer
Keeping connection-sync status and publish outcomes in two separate tables is a completely reasonable way to model two genuinely different operations — the failure isn't in having two tables, it's in never building the one read that combines them into the answer a client actually wants. Centriu's fix doesn't merge the underlying data; it adds the missing join, on read, so the question "is this working" gets one honest answer instead of two partial ones a person has to reconcile by hand.
Related systems
Main system: Centriu Atlas. Complementary when relevant: Centriu Axis.
What it does NOT do
- Does not return the actual access token or long-lived token value under any condition — only whether one is present.
- Does not repair, reauthenticate, or reconnect a broken channel connection — it reports the health status; fixing a broken connection remains a separate, deliberate action.
- Does not retry a failed post automatically — a surfaced failure is diagnostic information, not an automatic remediation.
- Does not evaluate channels beyond what a client has actually connected — a client with no social connections on file simply returns no rows for that client.
- Does not distinguish a temporary platform outage from a genuinely broken connection — both surface as recent publish failures with the same error-message detail; a person still interprets the cause.
- Does not guarantee every possible integration-health signal is captured — this tool reports the specific, measured signals (status, sync, token presence, 14-day publish outcomes) found missing in this audit.
Security and governance
The diagnostic resolves the requesting agent's own organization before reading any connection, and every row returned belongs to a client within that same organization. Authentication tokens are read only to check presence, never returned in the response. Any client data referenced remains subject to Brazil's LGPD (Law No. 13,709/2018). Full detail on access control lives at /governanca and /iso.
Pricing and contracting
Available by monthly subscription, with tiered plans. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
Why couldn't two staff members answer whether a client's connection was working?
The connection's sync status and its actual publish outcomes lived in two separate tables that nothing joined together — each person could see one half of the picture, but not both at once.
Does this tool ever expose an authentication token?
No — it reports only whether a token is present or absent for a given connection; the actual token value is never read into the tool's output.
What counts as proof a connection is genuinely working?
The tool's own guidance: an active status, a recent sync, AND real posts publishing successfully in the same 14-day window — sync health alone is not treated as sufficient proof.
Why did the output change from one object per connection to one line per connection?
The first version produced roughly 12,000 characters of output for just thirteen real clients — far more than a chat response can usefully display; the compact one-line format keeps the same information readable at real client volume.
Does the tool fix a broken connection it finds?
No — it diagnoses and reports; reconnecting or reauthenticating a broken channel remains a separate, deliberate action taken by a person.
What does Centriu Atlas cost?
It is sold by subscription with a published starting price — exact current values are on the central pricing page.
See how Centriu Atlas answers channel-connection questions in one call
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.