Read trigger logs

The endpoints behind the dashboard's Triggers and Executions pages also take your API key. With them you can see what each trigger did: its status, every attempt to send it, and the response your target returned. You can also replay a finished trigger.

curl "https://api.timetriggers.io/executions?httpStatus=5xx&limit=20" \
  -H "Authorization: Bearer YOUR_API_KEY"

To let an AI assistant read these logs for you, connect it to the MCP server. It uses these endpoints.

Authentication

Send your API key in ttr-api-keyheader or as Authorization: Bearer YOUR_API_KEY. A key sees the triggers of its own project. A signed-in dashboard session works too and sees every project you are a member of. A key that doesn't exist gets 401 Invalid api key, without falling back to the session. See Authentication.

Endpoints

Endpoint	Returns
`GET /jobs`	Your triggers, each with the outcome of its latest attempt
`GET /jobs/{id}`	One trigger, in the same shape
`GET /jobs/{id}/executions`	Every attempt of one trigger, with responses, newest first
`GET /executions`	Attempts across all your triggers, most recent first
`GET /executions/{id}`	One attempt, with its response
`POST /jobs/{id}/executions`	Replays a completed trigger

{id} is a trigger ID: the triggerId returned by /schedule, or the id of a /declare or /bulk operation. Each run of a recurring trigger is a trigger with its own ID. Its generatorId is the recurring trigger's ID. An ID that doesn't exist, or that belongs to another project, gets 404.

List triggers

GET /jobs takes these query parameters, all optional:

Parameter	Description
`status`	One trigger status, such as `completed` or `retrying`.
`id`	One trigger ID.
`title`, `customKey`	Case-insensitive substring. With either of them, `total` is `-1`, meaning not counted.
`tag`	Exact tag.
`limit`, `offset`	Page size (default 50, at most 100) and position.

registered triggers come soonest first; the others come by last activity, most recent first. Each row includes the request (httpMethod, httpUrl, httpHeaders, the body as httpBodyPreview and httpBodySize), the tags, and the latest attempt's attemptNumber, responseStatus, errorMessage and times.

List executions

GET /executions takes these query parameters, all optional, and they stack:

Parameter	Description
`jobId`	One trigger's attempts.
`customKey`	Attempts of the triggers with this exact custom key.
`jobStatus`	Attempts of the triggers currently in this status.
`executionStatus`	`planned`, `started`, `complete` or `cancelled`. See Execution statuses.
`httpStatus`	A status code such as `404`, or a class: `2xx`, `4xx`, `5xx`.
`deadLetterOnly`	`true` lists only dead letters. Any other value is ignored.
`limit`, `offset`	Page size (default 50, at most 200) and position. `total` stops counting at `10001`.

Rows carry the trigger's title, custom key, status, URL and method next to the attempt, but not the response headers and body: get those with GET /executions/{id} or GET /jobs/{id}/executions. The fields are described in Execution records.

Replay a trigger

curl -X POST https://api.timetriggers.io/jobs/TRIGGER_ID/executions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

This is the dashboard's Replay now / Retry now: it sends the trigger's stored request again, right away, and returns {"ok": true}. See Replay and retry for how the new attempt behaves.

Only completed triggers can be replayed. Any other status gets 400.
The body can set "triggeredBy" to "replay" or "retry", the label of the new attempt. Without it, the label is retry when the latest attempt failed (an error, or a status of 400 or higher) and replay otherwise, like the dashboard button.
A replayed trigger is queued until its new attempt finishes, so calling again in the meantime gets 400. Once it is completed again, each call sends the request again: make sure your target can take it twice. See Delivery guarantees.

Read trigger logs#

Authentication#

Endpoints#

List triggers#