Skip to content
Critique/docs
Architecture

Event-Driven Pipeline

How Critique accepts GitHub events, deduplicates work, and runs reviews asynchronously.

Critique’s GitHub integration is event-driven: the HTTP handler that receives a webhook returns quickly; durable work runs in background workers so traffic spikes do not cause timeouts or dropped deliveries.

Webhook ingestion

When GitHub sends an event:

  1. Critique verifies the payload signature.
  2. A delivery record is stored with a unique delivery id (GitHub’s X-GitHub-Delivery header) so retries do not double-run the same work.
  3. Processing is queued and GitHub receives an immediate success response.

You can think of deliveries as an audit log: received → processing → completed, failed, ignored, or deduplicated.

What happens next

A delivery worker interprets the event type:

Event familyTypical outcome
Pull requestQueue or update a review run
Check run rerequestedMay re-queue review when it matches Critique’s check
Push (default branch)May refresh repository index / embeddings
Installation changesSync repos; may enqueue indexing for new repositories
PR / review commentsBot mentions, commands, optional PR comment chat

Not every webhook invokes models — many update bookkeeping only.

Review processing

PR reviews are often multi-step:

  1. Gather evidence — diff, files, guidance docs, sandbox collectors when enabled.
  2. Run specialists and synthesis — parallel lanes, then verdict.
  3. Publish to GitHub — check run, summary, inline comments.

Long sandbox work is split so analysis can retry independently from final publication. See PR review for the user-visible story.

Other queued work

The same infrastructure also drives Remedy, builder jobs, chat runs, and repository indexing. Each job type has its own handler but shares signature verification, retries, and delivery records.

Outbound webhooks (Platform API)

When reviews, Checkpoint gates, Remedy runs, or passport snapshots complete, Critique can POST signed JSON to HTTPS endpoints you register per GitHub App installation (manage:webhooks scope). Per-run callbacks are also available on POST /api/v1/reviews and Coding Agent run create.

ChannelUser-AgentTypical consumer
Installation lifecycleCritique-Lifecycle-Webhook/1.0Org-wide CI, merge bots, audit
Per-run reviewCritique-Review-Webhook/1.0Single pipeline job
Coding Agent runCritique-Coding-Agent-Webhook/1.0Sandbox automation

review.run.completed includes inline findings[] for agent orchestrators. Full payload reference: Merge Gate API — Webhooks.

Delivery is fire-and-forget in v1 (single attempt, 8s timeout). Poll GET /api/v1/review-runs/:id?findings=all if a webhook misses.

Reliability

  • Idempotency — Duplicate GitHub deliveries are detected and skipped when safe.
  • Retries — Transient failures can be retried by the queue; operators may replay stuck deliveries from internal tools.
  • Lazy sync — Installation metadata is refreshed on hot paths so occasional missed webhooks do not strand repos permanently.

This page is an operator overview. Exact route names, queue products, and schema fields are internal implementation details subject to change.