How do I use the Codex CLI to investigate PagerDuty incidents with Tares?

Tares lets the Codex CLI investigate PagerDuty incidents: PagerDuty posts to a Tares webhook source, Codex connects over MCP, and you ask about the service that alerted. Codex then answers from the incident together with the logs, metrics and findings around it. PagerDuty reaches Tares through the webhook connector and a PagerDuty-side setup, because Tares has no connector of its own for PagerDuty today.

How it works

Two paths meet on one timeline.

• Incoming incidents. A PagerDuty v3 webhook subscription delivers each incident event to the ingest URL of a Tares webhook source. Tares stores the payload lossless, so the full event is kept, including the nested data.
• Reading back. Codex connects to the Tares MCP endpoint and discovers the Tares tools. The read tool returns a correlated, time-ordered timeline across all sources that match a label selector, such as one service.
• The link between them. Sources that carry the same label value land on the same timeline. Give the PagerDuty source the same service label value as your metrics and logs, and a question about that service returns the alert next to the evidence.

The webhook source reads labels from top-level fields or one-level dotted fields such as event.event_type. It takes a fixed event_type, because event_type_field reads top-level fields only. The incident’s service name sits deeper in the payload, so scope the PagerDuty subscription to one service and give the source a constant service label. Do not set signature_scheme: PagerDuty signs with a v1= prefixed header that hmac_sha256 does not accept, so the Authorization header is the credential.

Set it up

1. Start Tares locally, then start the MCP endpoint in a second terminal. Skip this on a server or Tares Cloud, where the MCP server already runs and the console’s Connect page shows your endpoint.

tares up
tares mcp --transport streamable-http

2. Create a webhook source for PagerDuty under Sources → Add source → webhook, or declare it in YAML. The constant service label should match the value your other sources use for the service the subscription covers. Copy the ingest URL from the source page.

- name: pagerduty
  connector: webhook
  config:
    event_type: pagerduty_incident
    labels:
      - { name: service, const: checkout, primary: true }
      - { name: incident_event, field: event.event_type }

3. In PagerDuty, create a v3 webhook subscription, in the console or with the Webhook Subscriptions API, and set its delivery URL to the Tares ingest URL. Choose the events, such as incident.triggered and incident.resolved, and the scope: account, team or service. When Tares has auth on, add a custom header to the delivery method: an Authorization header with the Bearer scheme holding an ingest-scoped API key. On an open local instance no header is needed.

4. Connect Codex to the MCP endpoint. Keep --url before the URL, because a bare URL registers a stdio server.

codex mcp add tares --url http://localhost:8788/mcp

5. For a remote, secured instance, Codex reads the credential from an environment variable. Use a key with the read scope rather than the root token.

export TARES_API_KEY=<api-key>
codex mcp add tares --url https://<your-host>/mcp \
  --bearer-token-env-var TARES_API_KEY

6. Check the connection from Codex:

Use tares: what are you ingesting right now?

Codex calls catalog_list and lists your sources, including the PagerDuty one.

7. When PagerDuty pages you, ask about the service that alerted:

Use tares: what happened to checkout in the last 15 minutes?

Codex calls read with that service as the selector and answers from the correlated timeline. See connecting agents for every client and the full tool list.

What you get

• One answer instead of several tabs. The PagerDuty incident, the metrics, logs and alerts for the same service arrive in one read, ordered by time.
• A lossless record of each PagerDuty event, so Codex can read fields you did not map to labels.
• Resolved events on the same timeline as triggered ones, so Codex sees when an incident opened and closed relative to a deploy or a metric change.
• Findings recorded by agents, which Codex reads when it investigates. A later investigation starts from the earlier conclusion.
• The same setup works for the other MCP clients, so a teammate can use a different tool against the same evidence.

When something else fits

• If you want the investigation to start without anyone asking, add a trigger that wakes a Tares agent when the PagerDuty source receives an incident. The AI SRE guide walks through that push path and the pull path you set up here.
• If you only want to explore data in a browser, the console’s Ask chat reads the same timeline without an external client.

Related