Acknowledge & resolve

The two buttons that move work through the inbox. They sound similar; they mean different things.

Acknowledge

Acknowledging says: "Someone has eyes on this. It's no longer unowned."

Use it when:

• You've read the change but haven't decided what to do.
• Someone else needs to be the one who actually fixes it, but you've routed it to them.
• You're investigating downstream impact before deciding.

Acknowledged changes don't re-ping. They sit in the Acknowledged column until someone resolves them.

Resolve

Resolving says: "The work this change implies is done."

Use it when:

• The code update has shipped.
• The change doesn't actually affect you (after investigation).
• You decided to accept the deprecation as-is and there's no work to do.

Resolved changes drop out of the Open queue but stay in history. You can always reopen.

The difference, in one example

Stripe announces a breaking change to /customers. You read the alert in Slack at 9am.

• 9:00am — Read the diff. Looks real. Acknowledge so the rest of the team knows it's covered. Assign to the engineer who owns the billing service.
• 9:30am — Engineer reads the change, looks at the code, files a PR.
• 2:00pm — PR ships. Engineer resolves the change with the PR link in the comment.

Two buttons, four lines of comments, ten minutes of human work, and the next person who looks at this change has the whole story.

Re-ping windows

Open changes that nobody acknowledges within a window get re-sent to the routing channel. Default windows:

• Breaking — re-ping after 1 hour.
• Risky — re-ping after 24 hours.
• Safe — no re-ping.

Tune at Settings → Alert preferences → Re-ping. Acknowledging stops the clock.

Bulk actions

When you've been on vacation and there's a backlog: shift-click to select multiple changes in the inbox, then bulk-acknowledge or bulk-resolve. Use this carefully — it's faster than reading them, which is the whole point.