How do I feed incident data into Tares from my own scripts?

Tares takes incident data from any script that can send an HTTP request. You create a webhook source over the HTTP API, POST JSON events to its ingest URL, and read a correlated timeline back with one call. You can export the whole setup as YAML to keep it in git.

How it works

Everything the console and the MCP tools do goes through the HTTP API of the Tares daemon, so your scripts can drive the same loop with curl or any HTTP client. For the full walkthrough, see The HTTP API in five minutes. It fits into the wider AI SRE workflow.

• Create a source. A webhook source accepts arbitrary JSON or NDJSON. Its config maps payload fields into the event envelope with labels, and the label marked primary is the entity key.
• Post events. Your script POSTs one object, a list or NDJSON to the source’s ingest URL. Tares stores the full payload lossless. Numeric fields such as latency_ms become typed fields that triggers can aggregate over.
• Read the timeline. You send a label and value selector and a time window to /read. Tares returns the events for that entity, time-ordered, from every source that carries the label. You can narrow the read to named sources or to one project.
• Keep the catalog. Sources and triggers are catalog state, and YAML is their portable form.

The ingest key in the create response is the stable, unguessable path for network delivery. Locally you can also post to a source by its name.

Set it up

1. Start the daemon. The API listens at http://127.0.0.1:8787.

   tares up

2. Create a webhook source. The primary label is the entity key. The response includes the ingest_key.

   curl -s -XPOST localhost:8787/api/sources -H 'content-type: application/json' -d '{
     "name": "checkout_probe",
     "connector": "webhook",
     "config": {
       "event_type": "probe",
       "text_template": "latency {latency_ms}ms on {endpoint}",
       "labels": [{ "name": "service", "field": "service", "primary": true }]
     }
   }'

   The same source in YAML form, as you would declare it in the catalog or add in the console, looks like this:

   - name: ci-events
     connector: webhook
     config:
       event_type_field: action
       text_template: '{action} by {sender}'
       labels:
         - { name: pipeline, field: pipeline, primary: true }

3. Post events from your script. Use the ingest key as the path when producers deliver over the network.

   curl -s -XPOST localhost:8787/ingest/checkout_probe -H 'content-type: application/json' \
     -d '{"service": "checkout", "endpoint": "/pay", "latency_ms": 1450}'

   On a secured instance, started with tares up --auth, the sender uses a Bearer Authorization header holding an ingest-scoped API key. Tares needs it only when auth is on.

4. Read the correlated timeline for one entity across all sources.

   curl -s -XPOST localhost:8787/read -H 'content-type: application/json' \
     -d '{"selector": {"service": "checkout"}, "window": "15m"}'

   To read only some sources, add a sources list to the body, or name a project.

5. Export the catalog as YAML and keep it in git.

   curl -s localhost:8787/api/catalog/export > catalog.yaml

   A fresh daemon reproduces the whole setup from that file on first boot.

   TARES_CATALOG=catalog.yaml tares up

To check your label mapping before you wire up a script, ask a connected agent to run test_source with a sample payload. After posting, open Recent events on the source page. Fields shows which payload fields arrive and how often, which helps you pick a reliable key.

What you get

• A single ingest URL per source that any script, cron job, CI step or service can POST to.
• Lossless payload storage, with labels that map the fields you care about into the envelope.
• Typed numeric fields that triggers can aggregate over, for example a maximum latency in a five-minute window.
• One time-ordered timeline per entity, merged from every source that carries the label. The value grows as logs, metrics and commits arrive interleaved on one clock.
• A trigger that wakes a subscriber with the correlated timeline attached, so your agent starts with context instead of fetching it.
• A catalog you can export, review in git, import with merge or replace, and use to rebuild a daemon. Imports are validated as a whole before anything is written.
• Sources and triggers you create without naming a project land in the Default project. Name a project when you create them to keep a job separate.

When something else fits

• If the data already comes from Prometheus, Alertmanager, Docker logs, Postgres or OTLP, use that connector. Tares then collects or receives the data in its own format and you write no sending script.
• If you would rather not call the API by hand, ask a connected agent to create the source and return the ingest URL, or use Sources → Add source → webhook in the console.

Related