add_incident_note
Write a diagnosis note on an incident—even if unresolved—so the person paged sees what failed and what you did, not just a timestamp.
Instructions
Requires an API key with the write scope or higher. Write back, in your own words, what you found out about an incident — so the person who gets paged reads a diagnosis instead of a timestamp: 'failed because the upstream API returned 503; same failure as the last three nights; I retried twice and stopped' instead of 'check failed at 03:04'. The note appears on the incident's page in the dashboard, attributed to its author, in the order it was written. Take incident_id from list_open_incidents. SEND A NOTE WHETHER OR NOT YOU COULD FIX THE PROBLEM. The person reading the alert cannot see what you saw. With no note, an incident is indistinguishable from one nobody has looked at yet, so an agent that writes back only its successes leaves a record worse than none: every unexplained incident then reads as 'not looked at yet' when it may equally mean 'looked at and gave up'. 'Could not reproduce; gave up after two attempts' IS a finding and is worth writing. NOTES ARE APPEND-ONLY. There is no way to edit a note and no way to delete one — not merely unexposed: no route and no query exists for either, and an edit is refused by the database itself. A correction is a new note, never an edit, because a diagnosis whose history a reader cannot trust is not evidence. This is NOT a write-once resource: a second, third or tenth note on the same incident is normal and expected, and there is no conflict for writing one. The only conflict this tool has is the cap of 50 notes per incident, and reaching it means something is looping rather than diagnosing. A CLOSED incident still accepts notes, on purpose: the run that finally succeeded is usually the one that understood why the previous one did not, so refusing the note would lose the explanation exactly when it became available. Authorship is not yours to choose — every note written through this tool is stored as author 'agent', because this is the API-key surface; there is no author argument and supplying one is not possible.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The diagnosis, in plain words and one or two sentences: what actually failed, whether it is the same failure as before (compare failure_signature.occurrences from list_open_incidents), and what you did about it. Must not be empty or whitespace-only, and must be at most 8192 bytes. An oversized body is REJECTED, never truncated — a truncated diagnosis reads as a complete one that trails off, and the reader cannot tell that the sentence naming the cause was the one cut — so shorten it and call again. A pasted stack trace is a note nobody reads: the full failure output already lives on the run that produced it. | |
| incident_id | Yes | The incident's numeric id, taken straight from an entry's incident_id in list_open_incidents. An integer, not a UUID. |