From Production Errors to Pull Requests with the Monitor Agent

Production errors are most useful when they land in front of someone who can act on them. The Monitor Agent add on connects your running app to Codex Infinity so that new bugs become tasks an agent can investigate.

What it does

• Accepts error events and metric samples through a public ingest API.
• Stores the raw data in the control plane for your review.
• Groups similar bugs using a lightweight local embedding model, with heuristic fallbacks.
• Rate limits repeated task creation for similar failures.
• Shows an owner dashboard under the add ons UI.

Send your first event

Provisioning the add on gives you an ingest key. Check connectivity with GET /api/monitor/v1/health, then POST to /api/monitor/v1/ingest with your key in the X-API-Key header. The body carries a source, service, environment, language, and lists of events and metrics. An event includes a level, event type, error class, message, and stack trace. A metric includes a name, type, unit, and value, such as queue.depth as a gauge.

Use the injected environment variables

The add on provides CODEX_ADDON_MONITOR_PROJECT_REF, CODEX_ADDON_MONITOR_INGEST_URL, CODEX_ADDON_MONITOR_DASHBOARD_URL, and CODEX_ADDON_MONITOR_INGEST_KEY. Read them in your app's error handler and send a small JSON payload whenever an exception is caught. A few lines in your logging layer cover the whole service.

Why it helps

Teams often collect errors in one place and track work in another. Here the same platform that receives the event also runs the agent that proposes the fix, so the path from signal to pull request stays short and visible.

Add trigger words

Defaults cover common failure language, and you can extend them with trigger_words in the payload or add on config. Words such as "timeout" or "deadlock" help highlight the issues that deserve a repair task first.

Let grouping reduce duplicates

Similar reports are compared against recent history. The add on config exposes cooldown_hours (default 48), similarity_lookback_days (default 30), and similarity_threshold, so you decide how closely two bugs must match before they share one task. One repair task per root cause keeps your review queue short.

Read the dashboard

Owner routes under /api/projects/:repo/addons/:id/monitor/ provide a summary, issues, events, and metric series with hours and limit parameters. Check the summary daily, then open the issues list to see which problems produced tasks.

Practical tips

• Send the environment name (prod, staging) so you can focus on production first.
• Include the stack trace in each event, since it gives the agent the exact file and line to inspect.
• Report metrics such as queue depth alongside errors, which helps explain why failures cluster at certain times.
• Review the first few generated tasks and adjust trigger words until the queue reflects what matters to you.

Close the loop

Each repair task runs like any other agent task, ending in a branch and a pull request for you to review. Over time, the same error stops returning and your dashboard settles. Open the dashboard, add the Monitor Agent to a project, and send a test event to see the flow end to end.

Start with Codex Infinity or browse the full blog.