Create an issue

The existing conversation that requested this issue. Must be accessible to the caller and belong to the same project. Slack delivery to that conversation's channel replies in its thread.

Optional caller-supplied idempotency key. Reuse it only when retrying the same logical issue creation request; concurrent or timed-out retries with the same key reuse one issue and one usage-budget admission.

Project to create the issue in. Auto-filled from CLI and SDK context when omitted.

Stable issue name for indexing and mute matching: at most 80 characters, plain English without emojis, in the form "<service or surface>: <customer-visible symptom>", without counts, timestamps, or internal identifiers. When omitted, the name is derived from contentMdx.

Issue report sent to the customer's engineer as written. Write brief, natural paragraphs without emojis, em dashes, headings or section labels. Lead with the observed problem and who is affected. Preserve measured scope, populations, denominators, time windows, useful diagnostics and verified evidence links. Separate observed impact from hypotheses; an exception or unhandled flag does not establish a failed request or customer harm. When the caller outcome is unknown, use this structure: your service reported the error at one useful code location; the operation outcome is unclear; optionally, conditional completion telemetry advice. Do not explain exception-handler mechanics or assume how the application should normally handle the error. State unknown outcomes directly, without apologies or a list of missing fields. End when the finding is complete: do not append a generic inspect/check command or repeat the diagnosis as a next step. Recommend a behavioral fix only after inspecting relevant code. When an important outcome remains unknown, query existing evidence first; if telemetry coverage is unknown, conditionally suggest the specific outcome fields and request/trace correlation that would clarify future occurrences. An absent field in one event does not prove telemetry is absent everywhere. At most 120 prose words and 3000 characters after Slack formatting; no minimum length. Keep literal technical evidence unchanged, omit irrelevant SDK metadata and Sazabi identifiers. Required unless sample is true.

Issue severity, by impact. critical: Happening now in production: an outage of the service, of a flow most users depend on, or of a whole feature; or data loss, a security exposure, or failed payments. high: Happening now in production: at least 1% of attempts failing or a region down; or production data loss, exposure, or failed payments that has stopped. medium: A failure limited to a few users or one path, a broad internal failure, a production outage that ended on its own, or serious harm outside production. low: No user or system impact, a transient blip, an internal failure on one item or a rare path, or other work outside production, including eval, training, and canary runs. When omitted, the issue is stored as medium and recorded as defaulted.

UUID of a registered component this issue belongs to. Required unless sample is true: every issue must be attributed to a component. List components first and pick the best match; register one if none fits. Missing or unknown IDs are rejected.

Optional ISO timestamp for when the linked status-page incident began.

Deprecated: the sample-issue onboarding step is a static exhibit and no longer creates an issue. Kept as a compat shim for @sazabi/cli <= 1.7.0 — the server marks the onboarding sample-issue step complete and returns a synthetic non-persisted issue snapshot. Mutually exclusive with the content inputs (name, contentMdx, severity, componentId, statusStartedAt); projectId stays allowed. Requires a user credential.

False when no new issue was created: deduplication judged the report the same problem as an existing open issue, which is returned as issue and records the report as a recurrence.

What happened, in one sentence: created, created as ignored, or not created and recorded on an existing issue.

Present when creation reused an existing open issue instead of creating a new one.

Present when deduplication judged the new issue a possible duplicate of this existing issue. A confident match is created with status ignored (reopen it to treat it as distinct); a less confident one is created open and delivered.