Incidents

Write back what you found out about an incident

The push half of failure delivery, and the reason the inbox is worth reading. Instead of "check failed at 03:04", the person who gets paged reads "failed because the upstream API returned 503; same failure as the last three nights; I retried twice and stopped."

Notes appear on the incident's page in the dashboard, attributed to their author, in the order they were written.

Send one whether or not you fixed the problem. 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 that is worse than none. "Could not reproduce, gave up after two attempts" is a finding.

Notes are append-only. There is no endpoint to edit one and none to delete one, by design: a diagnosis that can be rewritten is not evidence, and a reader has to be able to trust that a note still says what it said when it was written. Corrections are made by appending another note. Storage enforces this too: a stored note cannot be changed.

Authorship is not yours to choose. The request body has no author field. Authorship is derived from how the caller authenticated: a session principal (a person in the dashboard) is stored as user; an API key (a machine) is stored as agent. A reader must never be misled about who diagnosed what, and an endpoint whose caller could name its own author would make the distinction meaningless.

Notes may be added to a closed incident on purpose: the run that finally succeeded is usually the one that understood why the previous one did not, and refusing the note would lose the explanation exactly when it became available.

At most 50 notes per incident.

post/api/v1/incidents/{id}/notes

Request

  • Base URL: https://app.lastping.dev
  • URL: https://app.lastping.dev/api/v1/incidents/{id}/notes
  • Auth: API key in header X-Api-Key

Request body

bodystring required

What you found out, in two or three sentences: what you saw, what you tried, and where you stopped. Not a log dump — the failing run's own output is already stored and already shown beside your note.

Must not be empty or whitespace-only (400). Bodies over 8192 bytes are rejected, not truncated (400): a truncated diagnosis reads as a complete one that trails off, and the reader has no way to tell that the sentence naming the cause was the one cut.

Example request

{
  "body": "Upstream billing API returned 503 on all three retries; same failure as the last two nights. I stopped rather than risk re-charging anyone."
}

Response

The stored note.

idinteger required
incident_idinteger required

The incident this note is about.

author'agent' | 'user' required

Who wrote it. Decided by the surface the note arrived on, never by the caller: a session principal (a person in the dashboard) is user; an API key (a machine) is agent.

bodystring required
created_atstring date-time required

RFC 3339 UTC timestamp, stamped by the server.

Example response

{
  "id": 917,
  "incident_id": 4821,
  "author": "agent",
  "body": "Upstream billing API returned 503 on all three retries; same failure as the last two nights. I stopped rather than risk re-charging anyone.",
  "created_at": "2026-08-23T03:19:44Z"
}

Changes

No recorded changes to this operation across all 2 revisions of this API.