At exactly the due time, is an unresolved item overdue? What if it was resolved at that same second? An SLA report needs a precise answer before it labels operational work. A fixed review timestamp also makes yesterday's calculation reproducible tomorrow. Rather than consulting a moving clock, submit the clock you want the report to use and preserve it with the input.
I maintain the us-brand-signal-sla-checker Actor. This walkthrough describes its published build 0.2.2, inspected on 16 October 2026. The example below is synthetic and reviewed against that contract; it was not executed for this article. AI-assisted drafting was followed by a separate factual and editorial review.
The SLA Checker takes asOf plus rows containing openedAt, dueAt, and a nullable resolvedAt. The sample describes a fictional item opened at 08:00 UTC and still unresolved at its 09:00 due time. Its input schema is 1.1. All timestamps use real UTC seconds. This is a small boundary illustration, not an observation from a ticketing system.
{
"schemaVersion": "1.1",
"asOf": "2026-10-01T09:00:00Z",
"rows": [
{
"itemId": "item-1",
"openedAt": "2026-10-01T08:00:00Z",
"dueAt": "2026-10-01T09:00:00Z",
"resolvedAt": null
}
]
}
For an unresolved row, the contract uses asOf >= dueAt. The example therefore falls into open_overdue with zero overdue seconds. That is a meaningful boundary case: the overdue classification begins at the deadline, while elapsed time beyond it is still zero. By contrast, a row resolved exactly at its due time is classified on_time. Do not replace both rules with one generic strict-greater comparison.
The four possible outcomes are on_time, late, open_overdue, and open_within_sla. They are computed from the dates supplied by the caller. They do not establish which commercial SLA applies, whether a holiday should extend a deadline, or whether a ticket's status is truthful. This Actor does not query a support system or calculate business-hour calendars.
Inspect each row's classification and its interval fields. One subtle field name deserves attention: for unresolved rows, openedToResolvedSeconds carries age from opening to the supplied asOf. There has been no resolution, so presenting that value as actual resolution duration would mislead a reader. Your report surface should explain that convention or label the unresolved case explicitly.
The contract rejects impossible date relationships rather than fixing them. Opening must not be after the review timestamp or due date; a non-null resolution must be between opening and review. Keep these validation failures separate from legitimate late or overdue outcomes. A bad timestamp packet is not evidence that a team breached an agreement.
For a periodic review, capture a clearly named UTC cutoff and export the relevant item dates from your authorized source. Save the original export, submitted asOf, schema version, and returned digests. Rows are sorted by item ID, and canonical object-key ordering supports stable report comparison. With a different review cutoff, an unresolved item can legitimately change classification even when its own dates remain unchanged.
Up to 100 unique item IDs fit within a 48 KiB input and report limit, with a separate 60 KiB receipt bound. Oversized packets fail rather than silently losing late items. The output's decision confidence and freshness fields describe limited computation over the packet; they do not establish operational compliance or live monitoring. A human owner still needs to confirm the applicable SLA and source records before treating a label as an accepted business finding.
On the observed FREE pricing tier, one result-found event costs $0.01 for the complete useful report or plan, rather than each input row. FREE is the tier name, not a promise of free execution. Automatic Actor-start pricing is also present at $0.005 per GB, with a minimum of one event. Check the Actor page and your account tier before running; this is not a fixed total invoice, and a failed or repeated run may still incur applicable charges.
To try this deliberately, open the Actor page, select build 0.2.2, and submit the JSON as input. Set an explicit spending ceiling appropriate to your account; for example, $0.05 is a ceiling, not a quoted run price or a guarantee of a delivered report. Save the returned run ID and verify its immutable build ID. A local timeout does not cancel the remote run: inspect that same run before considering another attempt. Read the completed run's Dataset report and its separate OUTPUT receipt together; structural output is not independent source verification.
Top comments (0)