What to measure for Sume API jobs: metrics, labels and alerts

Five measurements cover most of what goes wrong in a Sume integration: submit outcome, time spent queued, time to terminal, terminal error code, and the gap between a job finishing and your webhook handler seeing it. All of them come from fields the API already returns.

The measurements

Use the job status vocabulary as labels, because it is a closed set: queued, processing, completed, failed, canceled. Use error.code for submit failures. Keep job ids and request ids out of metric labels and in logs, where high cardinality is fine.

Alerts that are worth waking up for

Alert on a rising share of 402 insufficient_credits, since retrying never helps and it means spend or top-up drifted. Alert on any sustained queue_full, which means you submit faster than the plan processes. Alert on webhook gaps, then fall back to polling status_url; the docs describe delivery as an optimization, never the only recovery path.

Where the timestamps live

GET /v1/jobs/:id/events returns a public timeline with job.created, job.queued, job.started, generation.submitted, and the terminal events, plus webhook.delivery. Read it for one slow job rather than polling it for every job.