How we use Regle to run Regle

The first time we got paged for the production Regle cluster, we did exactly what every other on-call engineer does: we opened seven tabs and started guessing. This was, to put it mildly, embarrassing for a company whose pitch is "don't guess what changed."

So we wired our own product into our own incident loop. Here's what that looks like now, concretely, in case it's useful as a template for your own setup.

The stack we run

Regle itself is small. A Go API behind a managed Postgres, a Next.js web app, a Rust event-ingestion service (more on that one in the ReQL post), and a handful of background workers. We ship 10-to-30 changes a week between the two of us, almost all through GitHub Actions to GCP.

Alerts come from a small Grafana stack that watches the API tier plus a few Healthchecks.io heartbeats for the background workers. When something fires, PagerDuty pages whichever of us is on-call that week.

How our own events flow into Regle

Every GitHub Actions deploy job ends with a single curl to our own Change API:

# .github/actions/notify-regle/action.yml
- name: Notify Regle
  shell: bash
  run: |
    curl -sS -X POST "$REGLE_INGEST_URL" \
      -H "Authorization: Bearer $REGLE_INGEST_TOKEN" \
      -H "Content-Type: application/json" \
      -d @- <<EOF
    {
      "kind": "deploy",
      "service": "${{ inputs.service }}",
      "environment": "${{ inputs.env }}",
      "sha": "${{ github.sha }}",
      "actor": "${{ github.actor }}",
      "pr_url": "${{ inputs.pr_url }}",
      "diff_summary": $(jq -Rs . < /tmp/diff_summary.txt)
    }
    EOF

That's the whole integration. There's no GitHub App, no OAuth flow, no "Connect your repo" button. The same shape works for our config-flag flips (we use a tiny YAML-in-Postgres flagger, not LaunchDarkly) and for the rare Terraform apply.

PagerDuty points at the same Regle webhook, with a different event kind. Now every page, deploy, and flag flip is in one timeline, tagged with service and owner.

What it looks like at 2 AM

Two weeks ago at 23:47, an alert fired on our API tier: p95 latency > 1.2s for 3 minutes. The on-call (Paul) opened Regle on his phone before opening Grafana on his laptop. The timeline showed:

• 23:42 — flag flip: cache_v2_router → 25%, by Jason. Touched: API tier. Likely cause badge.
• 23:09 — deploy: regle-web @ a18ef, by Jason. Touched: frontend only. Unrelated.

Paul flipped the flag back to 0%. Latency recovered in 90 seconds. Total time from page to action: under two minutes. The Grafana tab was still loading.

The next morning Jason actually fixed the bug — turned out a cache key collision under a specific tenant id. The post-mortem was a five-line edit on the AI-drafted timeline Regle produced automatically.

Why this matters even at our scale

We're two people. We don't have a war room. We don't have a dashboard wall. We have one tired engineer, a phone, and the laptop they grabbed off the nightstand. If our own tool can't collapse a 30-minute manual triage into a 2-minute answer at this scale, it definitely can't do it for a 50-engineer company.

It can. We do this every couple of weeks now, and the on-call experience went from "the worst part of the week" to "an annoying thing you handle in seven minutes from bed."

The pieces that aren't glamorous but matter most

• Owners are derived, not assigned. We feed CODEOWNERS into Regle on every deploy event. Every change knows whose weekend it's about to ruin, automatically.
• Mobile is the default. The first thing we built was the phone-first timeline view, because that's where 90% of on-call triage actually happens.
• One webhook, many sources. Adding a new event source (Healthchecks, Stripe webhook, etc.) is a five-minute ReQL package, not an integration project.

If you want to do the same thing

Sign up at app.regle.dev, point your alerting tool's webhook at the URL we give you, and add a single curl to your deploy job. That's the whole setup. We made it that small on purpose, because we wanted to do it that fast ourselves.