Add monitor response log API endpoints

[potofpie]

Why

When an OpenStatus monitor alerts, the dashboard has useful per-request debugging context: the exact response-log row, region, status code, latency, response headers, assertions, and timing data. Today that information is only practical to inspect manually in the dashboard.

This adds a programmatic way for operators and agents to fetch the same response-log context from an API key, so an alert can be turned into an investigation payload without screen-scraping the dashboard.

The main use case is incident investigation. Many internal platforms include correlation identifiers in response headers, such as trace IDs, request IDs, session IDs, deployment IDs, or thread IDs. Those IDs are often the thing an operator needs to kick off a deeper investigation in tracing/logging systems. If a monitor fails, the agent can fetch the failed response log, read the non-sensitive correlation headers, and use those IDs to start the next investigation step.

Example workflow:

1. A monitor alert fires in Slack.
2. An operator or agent gets the latest response logs for that monitor.
3. The operator or agent fetches the specific failed log by ID.
4. The returned headers contain correlation IDs such as x-trace-id, x-request-id, or deployment/session identifiers.
5. Those IDs are passed into debugging or incident-investigation tooling.

What changed

• Add response-log list/detail methods to the ConnectRPC monitor service:
  • ListMonitorResponseLogs
  • GetMonitorResponseLog
• Keep response-log access scoped through the authenticated workspace and monitor ownership checks.
• Limit response-log access to HTTP monitors and the existing response-logs workspace entitlement.
• Return bounded paginated list results with limit, offset, hasMore, and nextOffset.
• Return detailed response-log metadata: URL, status classification, status code, latency, region, trigger, timestamps, timing phases, assertions, and redacted response headers.
• Remove the earlier v1 Hono response-log endpoints so the public surface lives in the v2/ConnectRPC API.
• Update the Tinybird 14d HTTP list pipe so limit/offset are optional and existing dashboard callers are not capped by default.

Privacy and safety

• Response bodies are intentionally not exposed by this API.
• Response headers are redacted before leaving the API for common sensitive names and patterns, including auth, cookie, credential, key, secret, session, and token-bearing headers.
• Non-sensitive correlation headers such as trace IDs, request IDs, deployment IDs, and similar operational identifiers remain available so downstream debugging tools can use them.
• The API requires a valid x-openstatus-key and resolves the workspace from that key before reading any monitor/log data.

Possible follow-up

A useful next step would be monitor-level configuration for response-log header exposure. The monitor settings UI could let users define an allow list of headers that should remain visible in API responses, while all other headers are redacted by default. That would make the operational debugging contract explicit per monitor, for example allowing x-trace-id, x-request-id, or x-deployment, without relying only on global redaction heuristics.

Validation

• bun --env-file=apps/server/.env.test test apps/server/src/routes/rpc/handlers/monitor/__tests__/monitor.test.ts apps/server/src/routes/rpc/handlers/monitor/response-logs.test.ts apps/server/src/routes/v1/monitors/get.test.ts
• git diff --check
• Local API-key smoke test against the new ConnectRPC endpoint:
  • list response logs for monitor 6
  • fetch a failing response log by ID
  • verify sensitive headers are redacted
  • verify the response body is not present
  • verify operational correlation headers remain available for follow-up investigation

Notes

This intentionally keeps offset pagination because the existing ConnectRPC list APIs in this repo use limit/offset. The response-log request also supports timestamp bounds, so callers that need a stable time window can page within an explicit fromTimestamp / toTimestamp range.

[vercel]

@potofpie is attempting to deploy a commit to the OpenStatus Team on Vercel.

A member of the Team first needs to authorize it.

[cubic-dev-ai]

1 issue found across 12 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/server/src/routes/rpc/handlers/monitor/__tests__/monitor.test.ts">

<violation number="1" location="apps/server/src/routes/rpc/handlers/monitor/__tests__/monitor.test.ts:2511">
P2: The workspace-isolation test uses a hardcoded id instead of a real foreign-workspace monitor, so it does not actually prove the authorization boundary it claims to cover.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}