Use Case

Queue GitHub webhooks for CI/CD

GitHub sends webhooks for every push, pull_request, and release. Hooque buffers the flood so your pipeline can build and deploy sequentially — without losing triggers.

The Challenge

Webhooks are great as triggers — until they arrive concurrently and create build chaos. Reliable CI/CD pipelines depend on every deployment trigger across GitHub, GitLab, and Bitbucket.

GitHub sends webhooks for every push, PR, and release — floods during active development.

Parallel builds from concurrent webhooks cause race conditions and wasted compute.

If your CI endpoint is down during a deploy, events are lost and you miss the trigger.

How Hooque Solves It

Hooque turns bursty webhook triggers into a durable queue your CI workers can drain safely.

Provider

GitHub

push - pull_request - release

Buffer

Hooque

Durable queue + retries

Consume

CI workers

Build in order

  • Process builds sequentially from the queue to avoid race conditions.
  • Never lose deployment triggers — even if your CI is down temporarily.
  • Isolate per-repo credentials with per-queue API keys.

Before & After

Do not trigger expensive builds inside the webhook request. Pull events and control retries.

Without Hooque

Inline build triggers and concurrency storms

// GitHub webhook verification + processing in one request
import express from "express";

const app = express();
app.use(express.json());

// Public webhook endpoint: where should we host it so GitHub can always reach it?
app.post("/github/webhook", async (req, res) => {
  const signature = req.get("x-hub-signature-256");
  // This signature check is often forgotten when handlers are rushed.
  if (!verifyGithubSignature(req.rawBody, signature, process.env.GITHUB_WEBHOOK_SECRET)) {
    return res.status(401).send("invalid signature");
  }

  try {
    // Hope we do not timeout while processing inline.
    await process_cicd_payload(req.body); // push, pull_request, release
    res.sendStatus(200);
  } catch (err) {
    // Do we need to send an alert here?
    // How do we know which payload failed and how to debug it later?
    res.sendStatus(500);
  }
});

With Hooque

Durable queue + sequential processing

// Stream GitHub events from Hooque over SSE
const HOOQUE_URL = process.env.HOOQUE_URL; // e.g. https://app.hooque.io/queues/cons_github_webhooks
const TOKEN = process.env.HOOQUE_TOKEN;
const headers = { Authorization: `Bearer ${TOKEN}` };

// Signature verification is handled by Hooque before messages enter this stream.
const streamResp = await fetch(HOOQUE_URL + "/stream", { headers });

for await (const line of readSseLines(streamResp.body)) {
  if (!line.startsWith("data:")) continue;

  const event = JSON.parse(line.slice(5)); // { payload, meta }
  const payload = event.payload;
  const meta = event.meta;

  try {
    await process_cicd_payload(payload); // push, pull_request, release
    await fetch(meta.ackUrl, { method: "POST", headers });
  } catch (err) {
    // Failed message can be inspected in Hooque, and we receive an alert about it.
    await fetch(meta.nackUrl, {
      method: "POST",
      headers: { ...headers, "Content-Type": "application/json" },
      body: JSON.stringify({ reason: String(err) }),
    });
  }
}

Key Benefits

Make deployments predictable — even when GitHub events arrive in bursts.

Sequential build processing

Drain the queue with a single worker (or controlled concurrency) to eliminate races.

Zero lost triggers

Webhooks are persisted instantly so deploy events survive downtime and spikes.

Isolated per-repo keys

Give each repo or pipeline its own queue token so credentials stay scoped.

How It Works

Replace "webhook as deployment" with a queue you can control.

1

Create a webhook

Create a Hooque webhook and a queue for GitHub events.

2

Point GitHub to Hooque

Configure the webhook URL in GitHub to send push/PR/release events to Hooque.

3

Consume from the queue

Your CI worker pulls events and triggers builds with Ack/Nack retry control.

FAQ

CI/CD webhooks FAQ

Common questions about GitHub webhooks, ordering, and safe retries for pipelines.

GitHub still delivers to Hooque, and events stay queued until your CI worker comes back. You control when work is done by acking only after the build is safely triggered.
Yes. Enable GitHub verification so invalid signatures are rejected at ingest before they reach your pipeline.
Assume retries and duplicates. Drain the queue sequentially, and use a stable idempotency key (for example, delivery/message id or commit SHA + event type) so triggering a build is safe to repeat.
Yes. Bursts are buffered into a durable queue so your CI can drain at a controlled rate without dropping deploy triggers.
If the failure is transient (runner unavailable, network, rate limits), nack the delivery and retry. If the payload is invalid or the event should be ignored, reject it with a reason.
Yes. Use scoped API keys for consumers, and rotate/revoke them without changing your GitHub webhook configuration.

Still have questions?

Contact our support team

Start Processing GitHub Webhooks in 2 Minutes

Buffer deploy triggers, drain events in order, and stop losing webhooks when your CI is busy.

Start for free

No credit card required