Traffic health

odnoga measures every one of your callers against its own normal and tells you when one stops calling, or suddenly calls far more than usual — and proves how many calls odnoga refused, so you know in the first minute whether the problem is yours or ours.

A gateway sees something your own monitoring usually does not: the shape of your traffic, per function, without you instrumenting anything.

The failure this catches

A scheduled job dies. Nothing errors — it simply stops running, so nothing is logged, no alert fires, and no dashboard turns red. The first sign is a report that is empty a week later.

odnoga sees it the same day, because it knows what normal looks like for that specific caller.

The two shapes it watches need opposite responses:

The sentence that matters

Every alert carries the count of calls odnoga itself refused in the same window, and it leads:

• Refusals zero — "odnoga refused none of these calls. Every request it received succeeded, so the change is on the calling side." You can stop wondering about us and go look at your scheduler.
• Refusals above zero — "odnoga refused N calls in this window — check the error codes before looking at your own system." The drop may well be ours, and we say so first.

No other monitoring you have can tell you which of those two it is, because no other monitoring sits on both sides of the call.

What gets watched

Each app / function pair you send, taken from the headers you already set:

x-odnoga-app: acme-web
x-odnoga-function: nightly-digest

Traffic without those headers is pooled as (unattributed) and cannot be watched individually — see End-user attribution. Batch jobs carry whatever the submitting call carried, so a nightly batch is watched like anything else.

Each caller lands in one of five states:

Why a caller can be judged at one window and not another

A normal is the median of the caller's own past windows, and it takes eight of them before anything is judged. So the window length decides how much calendar time that is: eight 6-hour windows is two days, eight daily windows is eight days. A function you deployed last week is readable at 6 hours and still learning at 24 — the same caller, the same traffic, a different amount of evidence.

Each caller shows how many windows it has and when it was first seen, so learning tells you when it will stop being learning rather than leaving you guessing. Nothing before a caller's first ever call is counted against it: a new function is new, not silent.

Where an alert is concerned, the window it was judged at travels with it, so an alert and a screen you opened at a different window never read as a contradiction.

Not crying wolf

An alert you learn to ignore is worse than none, so:

• Normal is a median, not an average, taken over the caller's own recent windows. A caller that is naturally spiky does not get flagged for being spiky.
• A volume floor. A caller doing three calls a day is not judged; a drop from 3 to 0 is noise.
• Confirmation. The anomaly has to hold for two windows in a row before anyone is emailed. One missed run is a blip.
• A cooldown, so one broken job does not email you hourly.
• A recovered notice when traffic returns, so silence after an alert never has to be interpreted.
• Nothing is sent during an odnoga incident. If we are the cause, you get one status update, not ninety alerts about your own integrations.

Every one of those is adjustable — see below.

When a stop is correct

Some stops are the job finishing. A backfill drains, a migration completes, a feature is retired — the caller really has stopped, and you really do not need to hear about it again. odnoga cannot know your queue is empty, so tell it: mark the caller expected, on the alert itself or from the caller list.

It is not a mute, and the distinction is deliberate:

• Watching stays on and the history keeps building.
• By default the expectation lasts only until that caller calls again, then clears itself — so if the job ever runs and stops again, you are told. Nothing to remember, and no way to quietly blind yourself to a real outage months later.
• Give it a number of days instead when you are pausing something on purpose.
• You can take it back at any time.

Marking a caller expected is an administrative action — a workspace admin, or an admin of the organisation the workspace belongs to. Clearing one is open to anyone in the workspace, because restoring visibility is never the risky direction. Both are recorded against the person who did it.

Through MCP this is traffic.expected.set and traffic.expected.clear.

Where you see it

• Workspace → Functions — your callers with their state, a chart of recent windows with the normal drawn behind it, and a count on the nav when something is wrong.
• Tenant admin → Traffic health — every workspace in your organisation on one screen.
• Email — to whoever you list under Workspace → Alerts.
• MCP — traffic.health, so a coding agent debugging "why did my job stop" can ask directly rather than guess. It returns the same states, the same baselines and the same refusal counts, and traffic.expected.set lets it close the loop when the stop turns out to be a finished job.

Tuning it

Workspace → Functions → Rules, or through MCP with traffic.settings.set:

Set at the workspace, or once for the whole organisation under Tenant admin → Traffic health. A workspace that sets nothing follows the organisation, which follows odnoga's defaults.

Availability

Included on Extend and Enterprise. On Growth it can be added to your subscription — it appears as a single line on the invoice you already get, prorated, and you can remove it the same way. See Pricing.

Related

• End-user attribution — setting the headers that make a caller identifiable in the first place
• Concurrent sessions — the other thing that makes calls stop
• Observability — the request log behind all of this