Daily Snapshot Scheduling and Verdict-Only Credential Verification Automation: A Job That Only Ran When Someone Was Watching

A backend function that correctly produces the right result when invoked can create the impression that the feature it belongs to is "working," especially if the screen that happens to call it is opened regularly enough that the gap goes unnoticed. The difference between that and a genuinely scheduled process is invisible from the outside on any day someone happens to open the right screen — and completely exposed on the first extended stretch where nobody does.

The daily ad-spend snapshot function itself worked correctly whenever it ran — the gap was that nothing ran it on a schedule at all. Other scheduled jobs existed for other parts of Centriu Maestro (a campaign monitor, several report generators), but none of them called this specific function, and a nearby job that DOES run on a real schedule reads a rolling 30-day window even for platforms where that window's day-to-day change is not a meaningful daily figure — the exact mismatch this same fix's reporting-side page describes, meaning that job could not simply be repurposed to cover the gap. The fix adds a dedicated, genuine schedule for the snapshot function itself, timed thirty minutes before the downstream reporting step that depends on its output, so that step always has the current day's snapshot available by the time it runs.

Rather than assume a newly-scheduled job would simply work because the function it calls already did, the very first real run was tested directly — by sending the identical request the schedule itself would send, using the platform's own internal dispatch mechanism, and reading back a genuine, unmodified response. That response was an authentication rejection. The schedule was presenting the current, correct service credential — sourced from the platform's own secure credential store — and the function was comparing it against an environment variable that still held an OLDER credential format, the same category of mismatch responsible for a separate, wider outage described on this pillar's companion page. Caught this way, on a brand-new schedule before it had ever run unnoticed, rather than discovered months later the way the wider version of the same defect was.

Instead of simply updating that one comparison to the current credential value — which would only be correct until the next rotation — the fix moves the entire authentication decision into the database itself, the same place the credential is actually stored and kept current. A dedicated database function accepts a presented credential and returns ONLY a boolean: does this match the current service credential, yes or no. The credential itself never crosses back out of the database as part of that answer. The comparison inside that function is performed on a cryptographic digest of each value rather than on the raw text directly, specifically so that how many leading characters happen to match does not influence anything observable about the comparison. And execute permission on this function is explicitly revoked from the public role, from anonymous access, and from ordinary authenticated users — three separate, explicit revocations, deliberately, because revoking access from only one of those roles would still leave a default grant intact for the others; permission is then granted only to the single internal role that legitimately needs to ask the question.

A new schedule is added for a function that has always worked correctly whenever a person's screen visit happened to trigger it. Rather than trust that the schedule will behave the same way, the exact request it will send is fired manually first, and the response is a real authentication rejection — caught immediately, on day one of the new schedule, instead of being discovered months later the way the underlying credential-format mismatch was found elsewhere on the platform.

Centriu Maestro's daily ad-spend snapshot now runs on a real, dedicated schedule rather than depending on someone opening a specific screen, and the authentication protecting that schedule's own trigger is a database-side yes/no decision that never exposes the credential itself and cannot be bypassed by a role that was never explicitly granted access to ask.

This page covers the scheduling and internal authentication of Centriu Maestro's own snapshot-producing job — it does not describe the correctness of the daily figures that job produces, which is covered separately, or any customer-facing scheduling feature; this is an internal reliability mechanism, not something a client configures.

Assuming a newly-added schedule works because the function underneath it already works is a reasonable-sounding shortcut that specifically fails to test the one thing that's actually new — the schedule's own request, sent the way the schedule sends it. Centriu Maestro's approach fires that exact request manually before relying on it, which is precisely how a brand-new authentication gap was caught on day one instead of months later.