What happened to the automation's items, bucketed over time.
Per bucket: items admitted, and transitions to DONE (`finished`), IGNORED (`setAside`) and DEAD (`dead`). These are events, not item states: an item re-driven after it finished and finished again counts in both buckets, and an item an operator set aside by hand counts as set aside. Admitted is not part of the other three, because an item usually finishes in a later bucket than it arrived in. Counted from the transition log, which is never purged, so the whole window is counted unless it is longer than 400 days; then only its last 400 days are, and `countedFromMs` says where counting began. Buckets with nothing in them are omitted.
Authorization
Bearer JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.
In: header
Path Parameters
The trigger identifier.
uuidThe tenant identifier
Query Parameters
Bucket width: HOUR, DAY (default) or WEEK.
"DAY""UNSPECIFIED" | "HOUR" | "DAY" | "WEEK"Window start as Unix milliseconds (inclusive). Defaults to 30 days before to.
int64Window end as Unix milliseconds (exclusive). Defaults to now.
int64Response Body
curl -X GET "https://api.fruxon.com/v1/tenants/string/triggers/497f6eca-6276-4993-bfeb-53cbbbba6f08/ledger/itemTimeseries"{
"triggerId": "00000000-0000-0000-0000-000000000000",
"interval": "HOUR",
"window": {
"fromMs": 0,
"toMs": 0
},
"countedFromMs": 0,
"points": [
{
"bucketStartMs": 0,
"admitted": 0,
"finished": 0,
"setAside": 0,
"dead": 0
}
]
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}One item's attempt history.
The append-only transition log (§6.6) — the accountability grain, answering "what happened to this item and why". The run tree answers the different question of why one attempt behaved badly; neither grain is asked to do the other's job.
What each pass admitted, dispatched, finished and spent.
The fire log with the ledger's own accounting joined onto it, newest pass first. The Fires tab already said a pass happened; this says what it did and what it cost, which is the pair that answers "at this rate, what will the rest of this backfill cost" before it is started rather than after. Counts come from the append-only transition log, not from the fire row, and a pass's runs are gathered by the claim that dispatched them rather than by timestamp — a sweep records itself after claiming, and its runs report their spend when they finish, so timestamps alone would credit every pass with the previous one's cost. `cost` therefore rises after `firedAt` as the pass drains, and a pass read moments after firing reports less than it will. `docs/design/item-ledger.md §6.5`.