How do I let an AI SRE look at Postgres tables when investigating a cron job that stopped?

Tares reads a Postgres table incrementally with the postgres connector, so each new or changed row becomes an event the agent can read. Point it at the table your cron job writes to, choose a cursor column, and mark the entity column, such as tenant_id, as the primary label. If the data sits behind an API instead, the http_poll connector polls any JSON endpoint on a schedule.

How it works

The Postgres table connector polls a table and stores one event per new or changed row.

• Cursor. A column that only ever grows tracks progress. Use an autoincrement id to catch inserts, or updated_at, the cursor that also catches updates. Each poll picks up only rows past the cursor.
• Entity key. The column you mark with a primary label, for example tenant_id, becomes the key. Rows land on that tenant’s timeline.
• Columns. columns selects what to pull. Leave it empty to pull every column. The cursor, key and time columns are always included.
• Event time. time_column sets the event time. By default it is the cursor if that is a timestamp, otherwise the ingest time.
• Discovery. Give Tares the connection URL and it lists the tables it can see. It then reads the chosen table’s columns and proposes the cursor and labels.

A Postgres reachable from the Tares host is the only prerequisite. The driver ships with Tares, so there is nothing extra to install.

A telemetry source lines up with these rows only if it carries a label with the same name and value. If your logs or metrics carry tenant_id with the same values, they share the key. If they do not, add a label that matches.

For the wider investigation workflow, see AI SRE.

Set it up

1. Make sure a Postgres is reachable from the Tares host, and have a connection URL for the database your cron job writes to.

2. Start Tares locally if it is not running yet:

   tares up

3. Open Sources, Add source, Postgres. Enter the Connection URL and press Discover. Pick the table. Tares proposes the cursor, the entity key and the labels from its columns.

4. Choose which columns to pull. All columns are pulled by default.

5. Save. The source looks like this in YAML:

   - name: orders
     connector: postgres
     poll: 10s
     config:
       dsn: postgresql://user:pass@host:5432/appdb
       table: orders
       cursor_column: updated_at
       columns: id,tenant_id,status,amount,updated_at   # empty = every column
       labels:
         - { name: tenant_id, field: tenant_id, primary: true }
         - { name: status, field: status }

   You can also send the same object to POST /api/sources. The dsn is stored as a secret. It is redacted in the API and omitted from catalog exports.

6. You can also ask a connected agent to do it, for example: use tares to ingest the orders table, keyed by tenant_id. The agent runs discovery, a dry run that fetches sample rows, and then creates the source.

7. Verify. Open the source. Recent events shows rows on the next poll. Fields reports each column’s coverage, so you can confirm the key column is reliably present.

Two more settings help. limit sets how many rows are fetched per poll. text_template writes a one-line summary per row, for example '{tenant_id}: {status} ${amount}'.

What you get

• Each new or changed row in the table arrives as an event, keyed by the entity column you marked as primary, such as tenant_id.
• The database and table names are available as label fields, whichever columns you pull.
• The Fields view shows how often each column appears, so you can spot a key column that is missing on some rows.
• If you pick updated_at as the cursor, updates to existing rows are picked up as well as inserts.
• Polling runs inside Tares. You do not write or run a script on your side.

When you investigate a cron job that stopped, these rows give the agent your application’s own data for the affected tenants, in addition to whatever your telemetry sources carry. A telemetry event joins them only through a label with the same name and value.

When something else fits

• Use the HTTP API (poll) connector when the data you need comes from a JSON endpoint rather than a table. It polls on a schedule and stores one event per item. payload_key points at the list in the reply, and id_field stops items from being stored twice.
• Use http_poll as well for a status page or a SaaS export. It supports a GET or POST request, with one credential sent in a header you name.
• Stay with the postgres connector when the rows themselves are the evidence. It reads the table directly and follows a cursor, so you do not need an API in front of the data.

Related