← FinOpsAid blog
Should I be worried about this spike? Reading the Alerts page and the anomaly feed
Alert severities, the anomaly feed's baseline and deviation columns, and the two-to-three-day lag — what each number on the FinOpsAid Alerts page means and when to act.
Alerts holds two different things that people tend to blur together. Alerts are rule violations — something you defined a threshold for, and it was crossed. Anomalies are statistical: a day that came in above its own trailing baseline, with no threshold involved.
One says "the thing you asked to be told about happened". The other says "this looks unusual compared to your recent normal". They need different responses, and the page keeps them in separate cards for exactly that reason.
Conventions used below are in the grammar behind every number.
The KPI row
| Tile |
What it counts |
Direction |
| Total Alerts |
All active alerts. |
Lower is better. |
| Critical |
Critical-severity alerts. Icon turns amber when non-zero. |
Lower is better. Should normally be zero. |
| Warning |
Warning-severity alerts. |
Lower is better. |
| Info |
Informational alerts. |
Neutral. |
| Anomalies |
Detected spikes. Footnote: "spikes vs baseline". |
Lower is better — but see the note on healthy volatility below. |
A Total that never moves is worth as much attention as one that spikes. Either nothing is going wrong, or your thresholds are set so loosely that nothing can trip them. The second is more common than the first.
Active alerts
| Column |
Meaning |
| Rule |
Which rule fired — this is what makes an alert actionable, because it names the thing you configured. |
| Message |
The human-readable statement of what happened. |
| Value |
The number that triggered it. |
| Severity |
Critical / warning / info, as a colour-coded chip. |
Most rows here trace back to a budget: crossing 80% raises a warning, crossing 100% raises an exceeded alert. That mapping is set on Budgets, which means the Alerts page is downstream of decisions you made there. A noisy alerts page is almost always a budget-configuration problem rather than an alerting problem.
An empty table reads "No active alerts."
The anomaly feed — how to read a row
Anomaly detection catches step changes, not drift. A cost that doubles overnight fires; a cost that creeps up 4% a week never will, because the baseline follows it. Both matter — they just need different pages.
The feed flattens all three monitored series into one list, most severe first, newest first within a severity.
| Column |
Meaning |
| Series |
Spend, AI credits, or CI minutes. |
| Date |
The day flagged. |
| Value |
What that day actually came in at. |
| Baseline |
What the trailing window expected. |
| Over |
Percentage above baseline, with a leading +, rendered in the alert colour. |
| Severity |
Critical / warning / info. |
Which series fired tells you where to look. A spend anomaly with no matching credits or minutes anomaly usually means a price or plan change rather than a usage change. Credits spiking without spend means you're still inside the allowance — early warning, not yet a bill. Minutes spiking points straight at GitHub Actions and a workflow change.
An empty feed reads "No upward spikes detected against the trailing baseline", which is precise about what was and wasn't checked.
The lag note at the bottom of the page
Credit/cost alerts lag ~2–3 days — they are not real-time. Real-time membership, workflow & runner signals arrive via webhooks.
This is the single most operationally important line on the page, and it sets expectations for the whole product. A cost anomaly on Tuesday surfaces on Thursday or Friday. That's inherent to GitHub's billing pipeline, not a sync problem, and it means anomaly alerts are for investigation rather than for interception. You cannot stop the spend that already happened; you can stop it recurring.
The things that are fast — membership changes, workflow events, runner state — arrive over webhooks, which is why permission drift shows up on Security far sooner than its cost consequence shows up here.
Making this page one people still read in six months
The failure mode of every alerting system is the same: too many alerts, muted, then ignored, then the one that mattered gets ignored too.
- Fewer budgets, better placed. Every budget is a potential alert source. One org guardrail, one per major product, one on a genuinely volatile team.
- Route by severity, not by volume. Critical should reach a person. Info belongs in a weekly digest.
- Treat a resolved anomaly as a rule candidate. If you investigated a spike and found a real cause, a threshold would have caught it sooner and with a name attached.
- Expect volatility in some series. CI minutes are naturally spiky — releases, dependency bumps, security scans. A series that alerts every week needs a wider baseline, not more attention.
That argument is made properly in alerts people don't mute and the detection method in spend anomaly detection.
What people get wrong on this page
- Expecting real-time cost alerts. Two to three days, structurally.
- Confusing alerts with anomalies. One is a rule you set; the other is statistics on your own history.
- Ignoring a quiet page. Silence may mean your thresholds can't fire.
- Expecting gradual drift to be caught. The baseline absorbs it. Use Cost Explorer for trends.
- Reading a spend anomaly as a usage problem. Check whether credits or minutes moved too.
The 60-second read
- Critical count. It should be zero; if it isn't, start there.
- Active alerts: read the Rule column — it names what you configured.
- Anomaly feed top rows: which series, and how far over baseline?
- Cross-check the series against the page that owns it before drawing a conclusion.
- If nothing has fired in a month, go back to Budgets and check your thresholds are reachable.
Frequently asked questions
What is the difference between an alert and an anomaly?
An alert is a rule violation — you defined a threshold and it was crossed. An anomaly is statistical: a day came in above its own trailing baseline with no threshold involved. One tells you the thing you asked about happened; the other tells you something looks unusual against your recent normal.
Can FinOpsAid alert me about GitHub spend in real time?
Not for cost. GitHub's billing pipeline lags roughly two to three days, so a cost anomaly on Tuesday surfaces on Thursday or Friday. Cost alerts are for investigation rather than interception. Membership, workflow and runner signals do arrive in near real time via webhooks.
Why is the anomaly feed empty when our costs are clearly rising?
Because the feed reports only upward spikes against a trailing baseline, and that baseline follows you — a cost creeping up a few percent a week is absorbed into it and never flagged. An empty feed says no day stood out against your recent normal, not that spend is flat. Sustained drift belongs on Cost Explorer.
Want alerts that fire before the invoice? Connect your GitHub org — read-only and free during beta — or explore the demo first. Next: how to read the Reports page.