Confirm story points are being read

You do not normally need to configure the field ids. Prism discovers them from Jira's own /rest/api/2/field registry on every run: it collects every field whose name is "Story Points" or "Story Point Estimate", then every field whose name merely contains "story point", and treats them as an ordered candidate list — coalescing per issue, first non-null wins. That design is deliberate, because on a large Jira each project configures its own fields and several story-point customfields coexist with different projects populating different ones. The sprint field is discovered the same way.

So the task here is not to find the ids. It is to confirm the discovery found something, because the failure is quiet: with no story-points field, the ingest succeeds, issues arrive, every point lands null, and nothing errors. Question counts stay right while anything about points is silently empty.

Two places tell you, and neither needs Jira access:

kubectl logs -n <namespace> -l app.kubernetes.io/component=jira-ingest | head -3

The first lines name the deployment, the candidate list and the sprint field:

jira ingest: Server @ https://jira.example.com | points candidates=['customfield_10004'] sprint=customfield_10007

An empty list is called out on its own line — WARNING: no story-points fields found — and the same finding reaches the self test through the upstream probe as no_story_points_field_found, a warning rather than a failure for the reason above: the source is degraded, not broken.

A matching name is not the same as the right field

Discovery matches on the field's name, and on a large instance more than one name matches while only one of them holds this issue's story points. Two shapes turn up repeatedly, and both are wrong in the same direction:

field	what it actually is	what it does to your figures
Total Story Points	a rollup onto the epic	where the epic has it and Story Points is null, the epic records its children's aggregate as its own — and Prism ingests those children too, so every sum counts them twice
Original story points	the estimate before re-pointing	the wrong number by construction for "what did this team deliver", and indistinguishable from the right one once it is in the column

Neither shows up as an error. The issue counts stay right, the points column stays populated, and only the arithmetic is wrong. So on an instance with more than one match, check which fields discovery found before trusting the numbers — and if the extras are wrong rather than merely redundant, name the right one explicitly below.

To override discovery, set ingest.jira.storyPointsField to a comma list of customfield_NNNNN ids. It replaces the discovered list rather than being added to it — the ids you name are the only ones that count, in the order you write them, and nothing discovered can supply a value behind them. That is the lever for the case above.

Changed in 0.9.0 (#602). It used to be prepended, which sounds like a stronger version of the same thing and is not: every discovered field stayed in the chain and supplied a value wherever the ids ahead of it were null. On an instance whose exact match already sorted first, setting the override changed nothing at all.

Leave it empty and discovery behaves exactly as described above, which is the normal case.

To read the ids off Jira yourself:

curl -sS -H "Authorization: Bearer <PAT>" "<your Jira base URL>/rest/api/2/field" \
  | grep -io '"id":"[^"]*","key[^}]*story point[^}]*'

If points are still null with a candidate list present, the likeliest cause is that the issues in the window simply have no points on them — check one in Jira before raising it.

And to answer "did the wrong field supply them?" — the question the table above raises — Admin → Context streams records points_field_by_project: which field supplied points for which project, as a count. A project whose points all came from a field you did not expect is visible there and nowhere else, so it is worth a look on the first run after go-live rather than only when a figure looks wrong. A project whose points never arrive at all is visible there too.

The upstream probe reports the same thing before any ingest has run: story_points_candidates is the chain the ingest will coalesce over, story_points_discovered is what discovery found regardless of your override — so an override that names the wrong id is visible as the difference between them.