Step 3 — Send

What each status means

Every issue reports its own outcome rather than sharing one tick with the batch. These are all the values a row can take:

The counters above the rows — Updated, Sending, Failed, and Status failed or Not sent when there are any — are running totals of the same values, and update live as the send goes.

Send guard

Some sends are worth a second look, so the send guard stops and describes the one you are about to make. Every line is counted from your actual batch, and lines with nothing to say do not appear.

Two of the limits are refusals rather than warnings. A single file over 150 MB is rejected the moment you attach it, and a send that would write more than 2 GB into Jira is stopped here, before anything posts. Everything else the guard raises is a confirmation you can accept — see Limits for every ceiling in one table.

The send guard appears when any one of these is true:

• the send reaches 10 or more issues
• any comment in it @mentions someone — they are notified once per issue, so a mention across 25 issues is 25 notifications
• the attachments come to 50 MB or more, which catches the send that is small in issue count and heavy in bytes
• any comment is a reply to a customer — at any size, because that one cannot be taken back

What it tells you. The heading names the riskiest thing about the send: Email 3 customers? when any reply is customer-facing, Post to 12 issues? when none is, or Move 4 issues? when the batch is status changes only. Underneath, in order:

• The customers, first and in the warning colour — “3 replies are set to Reply to customer — those customers get them by email. This cannot be undone.” First because it is the only irreversible part: a comment can be deleted, the email has left.
• What posts, and under whose name — “14 comments post under your name across 9 issues. The other 11 are internal.” Comments and issues are different numbers once a request carries both halves.
• Watchers — everyone watching each issue is notified.
• Mentions — called out separately, because a mention notifies once per issue.
• The storage arithmetic, on a heavy send only — “Keep this tab open. This send adds 1350 MB to Jira (150 MB × 9 issues). Make sure you have room for 1350 MB.” In practice this is the 50 MB line: a comment carrying 50 MB or more of files gets it, whatever the issue count. A second rule catches small files spread far enough to write 250 MB or more into Jira. Confirming acknowledges both halves — that the comment carries files this large, and that your site has room for the multiplied total. Either threshold alone is enough, since a file uploads once however many issues it lands on but its storage multiplies. The × shows only when the issues carry the same files.
• Video — a note that Jira may take a minute to process it, so a grey placeholder does not read as a failure.
• What is being skipped — “3 issues with no comment — skipped.”

The button repeats the number rather than saying “Confirm”: Post 14 — email 3 customers. Cancel takes focus, Esc closes, and tabbing stays inside — so the dangerous button is never the one your hands land on.

After sending

You land here as soon as the upload starts, not when posting finishes — on a send carrying files the upload is most of the wait. It reads Step 1 of 2 · Uploading 3 of 8 · 42 MB of 110 MB · 4.1 MB/s · ~0:16 left…, then Step 2 of 2 · Adding to issues, with Cancel under it throughout.

When the run finishes the heading names what the send actually did: Comments posted, or Status changes applied when the batch only moved issues, or Issues updated when it was a mix — and it tells you how long it took, down to took 3m 05s.

Alongside those, a service-project row carries the audience it reached, and a row whose issue also moved carries the move itself — named at both ends, WAITING FOR SUPPORT → ESCALATED, because afterwards the issue only shows where it ended up, so where it came from is precisely the part you can no longer look up.

Retry names what is left — Retry n failed, Send the remaining n, or Retry n unsent when there is some of each. It re-runs only issues where nothing was posted, which is why it skips an issue whose comment landed and whose status change was refused. Done clears the batch.

Every row says who saw it. On a service project a row carries SENT TO CUSTOMER, and adds + INTERNAL when that request also carried a note — same colours as everywhere else.

That badge is read back off the comment Jira created, not off what was requested — so the screen can tell you when the two disagree. A row can read visibility differs, or + Visibility unknown where Jira did not report on a second comment. Rare, and shown rather than smoothed over.

Every row opens its issue: click the issue key or the ↗ on the right and it opens in a new tab — scroll to the bottom of the issue to see the comment or the change that landed.

When something does not land

Most sends finish with nothing in the Failed column. When part of one does not land, it is one of three things.

The comment posted but the status change was refused

A comment that posted and a transition Jira rejected are two different things, counted separately: n status changes failed — the comments posted, change the status in Jira.

The column is separate on purpose, because Retry never re-runs an issue whose comment already landed — that would post it twice. Make those moves in Jira instead.

The commonest cause is the issue moving in Jira after you picked it, so the transition no longer exists from where it now sits. The row says exactly that.

The send ran out of time, or was interrupted

A send has a budget. Past it the app stops starting new issues and answers with what it has, marking the rest Not sent — the send ran out of time. Nothing was posted to this issue. Retry covers those alongside anything that failed — a known partial result is safe to retry, which is what the budget buys.

If the connection drops and no result comes back at all, Send is held: “the send was interrupted, so we don’t know which comments went through — check the issues in Jira before sending again”, until you press I’ve checked — let me send.

Most sends finish with nothing in the Failed column. When something does fail it is usually a permission change, or an issue that was moved or deleted while the batch was running — and the row carries the reason Jira returned.

If a retry keeps failing, tell us — send the issue keys and the reason shown against each failed row.