← FinOpsAid blog
Can I trust today's numbers? Reading the Sync Activity page
Run history, per-connector status, API call counts and records ingested — the admin page that tells you whether every other page in FinOpsAid is complete.
Sync Activity is the page that validates every other page. Nothing here is a cost figure — it's the ingestion log, and its job is to answer one question before you act on anything else: is the data complete?
It's an admin-only page. It doesn't appear in the sidebar for non-admin users, and that's intentional: it's diagnostic plumbing, not a reporting surface.
Why a data page matters in a cost tool
Every number in FinOpsAid is assembled from connectors that call vendor APIs on a schedule. Those APIs rate-limit, time out, and occasionally return partial results. When a connector fails, the affected pages don't break — they show slightly less data, which is far more dangerous than an obvious error, because a quiet undercount looks exactly like a saving.
This is the page that stops you reporting a sync failure as a saving. Thirty seconds here before a monthly report is the cheapest insurance in the product.
The KPI rows
Seven tiles across two rows, all counted over the retained run window.
| Tile |
What it counts |
Direction |
| Runs (window) |
Sync runs in the window. Footnote: "most recent first". |
Neutral. |
| Successful runs |
Runs where every source succeeded. Footnote: "all sources ok". |
Higher is better. |
| Runs with failures |
Runs where at least one source failed. Icon turns amber when non-zero. |
Lower is better. Zero is the target. |
| API calls |
Total calls, with an ok/failed split in the footnote. |
Neutral in total; the failed half is what matters. |
| Records ingested |
Total records written, across all runs. |
Higher generally means more complete — a sudden drop is a signal. |
| Successful API calls |
The ok half, on its own. |
Higher is better. |
| Failed API calls |
The failed half, on its own. |
Lower is better. |
The definition of Successful runs is strict on purpose: all sources ok. A run where eleven of twelve connectors worked counts as a failure, because a partial sync produces partial numbers and there's no honest way to call that a success.
Records ingested is the tile to watch across runs. A steady figure means the pipeline is behaving. A sharp drop with no failure count means a vendor API returned less than usual — which may be a real change in your org, or may be an upstream problem that didn't surface as an error.
If no runs exist at all, the page says so and offers a Run a sync now button rather than showing an empty table.
Run history
One row per run, newest first. Clicking a row loads it into the detail card below.
| Column |
Meaning |
| Run time |
When it started. Click to select. |
| Status |
Whether any source failed in that run. |
| Sources |
succeeded / total, with the succeeded count in green. The clearest completeness signal on the page. |
| Records |
Records processed. |
| Upserts |
Records actually written or updated — as distinct from processed. |
| API calls |
Calls made, with failures highlighted. |
| Duration |
How long the run took. |
Records versus Upserts is the interesting pair. A run that processed a lot and upserted little means most of what it fetched was unchanged — normal for a warehouse doing incremental sync. A run with high upserts is either a backfill or a period where a lot genuinely changed.
Duration is a leading indicator. A run time that creeps up over weeks usually means growing data volume or increasing rate-limit backoff, and it's the earliest warning that the sync window is going to become a problem.
Connector detail
The selected run, broken down per connector. The header repeats the run's summary — sources ok, records, duration — with a status chip.
| Column |
Meaning |
| Connector |
The source name, in monospace. |
| Status |
Green ok or red failed. |
| Records |
Records for this connector, or a dash when it failed. |
| Upserts |
Records written. |
| Duration |
Time spent on this connector. |
| API calls |
Calls, with failures highlighted. |
| Details |
The error message when it failed, rendered in the alert colour. Otherwise a dash. |
That last column is the whole point of the page. When a connector fails, the error text is here, and it usually names the cause directly — rate limiting, a permission the App doesn't hold, an endpoint the org isn't entitled to.
That third case matters and isn't a fault: an org without Copilot will fail the Copilot metrics connector, and an org that isn't part of an enterprise install will fail the enterprise-scoped one. Those are correct outcomes, and knowing which failures are structural for your org means you stop chasing them.
Run a sync now
A button at the top right triggers an on-demand sync, and a result banner reports what happened. Useful in three situations: verifying a newly added credential, refreshing after fixing a permission, and confirming that a failing connector now works.
It doesn't defeat vendor lag. GitHub billing is two to three days behind regardless of when you sync, so an on-demand run fetches the latest available data — not today's.
Which pages a failed connector affects
Map the connector name to the surface it feeds. Roughly:
What people get wrong on this page
- Skipping it before reporting. A drop caused by a failed connector is indistinguishable from a real saving on every other page.
- Reading a partial run as a success. Eleven of twelve sources is a failed run by this page's definition, and rightly so.
- Chasing structural failures. An org without Copilot will always fail the Copilot connector.
- Expecting an on-demand sync to defeat vendor lag. It fetches the latest available, which is still days behind for billing.
- Ignoring creeping duration. It's the earliest warning you'll get about the sync window.
The 60-second read
- Runs with failures: should be zero.
- Failed API calls: a non-zero count means partial data somewhere.
- Newest run's Sources column —
12 / 12 is what you want to see.
- If not, open Connector detail and read the Details column.
- Check Records ingested against previous runs before treating any cost drop as real.
Frequently asked questions
How do I know whether the numbers in FinOpsAid are complete?
Check the Sync Activity page before reporting anything. The newest run's Sources column should read the full count, such as 12 of 12. A partial run still renders every page and still looks plausible, so a failed connector is indistinguishable from a genuine cost saving anywhere else.
Why does a sync run with one failed connector count as a failure?
Because a partial sync produces partial numbers, and there is no honest way to call that a success. A run where eleven of twelve connectors worked will quietly under-report whichever surface the twelfth feeds, with nothing else in the product indicating it.
Some connectors always fail for our org. Is that a problem?
Not necessarily. An organization without Copilot will always fail the Copilot metrics connector, and one outside an enterprise install will fail enterprise-scoped endpoints. Those are correct outcomes. Read the error text in the Details column to tell a structural failure from a real one.
Want confidence in your own numbers? Connect your GitHub org — read-only and free during beta — or explore the demo first. Back to the index: the grammar behind every number.