Configure
Automations
Run review-adjacent work on a schedule or when something happens, and post the result to chat, trackers or email. Predictable, metered and approved before anything changes.
An automation does one useful job when something happens or on a schedule, and posts the result where your team works. You build it from four parts:
- When it runs: a schedule, or an event.
- Filters: which repositories, teams, labels, branches and severities it cares about.
- What it does: an action from the catalog, with settings you can change.
- Where it posts: a Slack, Microsoft Teams, Google Chat or Discord channel, a direct message, a tracker comment, or email.
Open Automations in the console sidebar, pick an action from the gallery, and follow the builder. Use Test to see the exact message before you save. A test never posts anything.
When it runs
On a schedule: every hour, every day, on weekdays, or once a week, at a time in your time zone. Daylight saving changes are handled for you: a run whose time is skipped when the clocks go forward runs once, just after the change, and a time that happens twice when the clocks go back runs once. If MergeHarbor was unavailable at a scheduled time, the automation runs once when it is back, not once per missed time.
When something happens:
| Event | What starts it |
|---|---|
| Pull request opened | A pull request is opened in a connected repository |
| Pull request merged | A pull request is merged |
| Review completed | MergeHarbor posts a review |
| Review found critical issues | A posted review has at least one critical finding |
| Merge gate blocked | A pull request’s merge gate changes to blocked |
| Alert | A new Sentry or Datadog issue or alerting monitor, or a PagerDuty incident |
| New issue | A new GitHub issue, or a Jira, Azure Boards, Linear or Asana issue sent through a signed webhook |
| Chat keyword | A message that mentions MergeHarbor in a mapped channel and contains one of your keywords |
| Inbound webhook | A signed request to the automation’s own URL |
Every event starts each matching automation once, even if it arrives twice.
The catalog
| Action | What you get |
|---|---|
| Pull requests waiting for review | A daily or weekly list of open pull requests that have waited longest |
| Risky merges summary | Recent merges with high risk, open critical findings or an overridden merge gate |
| Incident suspects | When an alert fires, the recently merged pull requests most likely to have caused it, and the changed files that match its stack trace |
| New issue triage | A suggested type, priority and owner team for a new issue, with related open pull requests |
| Stale pull request nudges | A direct message to each author whose pull request has had no activity for a few days |
| Review summary to the tracker | A short summary comment on the linked Jira, Azure Boards, Linear or Asana issue after a review |
| Fix pull request for critical findings | A fix pull request with the suggested fixes of a review’s critical findings |
| Custom instruction | Your own instruction over the event and recent pull requests, with a fixed message format |
Approvals
Anything that writes code or changes a tracker waits for a person. When a run of Fix pull request for critical findings, Review summary to the tracker, or triage with a tracker comment is ready, the run shows Waiting for approval with exactly what it will do, and the automation’s channels get a notice with a link. Approve or reject it in the run history. Runs nobody approves expire after 7 days.
Approving a fix pull request also needs the permission to open fix pull requests.
Credits
Every action except Custom instruction works from data MergeHarbor already has and uses no credits.
A custom instruction calls a model, so it has two limits you set in the builder:
- Per-run cap: the most one run can use. The builder tells you the smallest cap that fits your settings (the longest answer plus the most data a run sends), so a run can never go over it.
- Monthly budget: the most the automation can use in a calendar month (UTC). When the next run would go over it, the run is skipped and says why.
Runs also respect your organization’s spend limits and credit budget. Credits used appear on each run and in Usage.
Run history
Each run records what started it, what it read, each step, the message (or what it would have been), credits, how long it took, the outcome, and links to what it created. Secrets such as tokens and keys are removed from everything an automation posts or stores.
Pausing
- Pause an automation to stop it; Resume starts it again.
- Pause all on the Automations page stops every automation in your organization at once.
- Self-hosted operators can turn automations off for the whole installation.
Custom instructions
Write what you want in plain words, choose what the model can read (the triggering event, open pull requests, recent critical and major findings) and the longest answer. The answer always has the same shape: a title, a short summary and up to 20 lines, each with an optional link. Links are only kept when they appear in the data the model read.
The data is treated as untrusted: text inside a pull request, issue or alert cannot change your instruction, and attempts to do so are flagged on the run. Test shows what would be sent without calling the model; Test with the model shows a real answer and uses credits from the automation’s budget.
Inbound webhooks
Choose Inbound webhook as the trigger to get a URL and a signing secret (shown once; you can rotate it). Choose the format the sender uses:
| Format | Signature header |
|---|---|
| Generic | MergeHarbor-Signature: t=<unix seconds>,v1=<hex HMAC-SHA256 of "<t>.<body>">; body is a JSON object |
| PagerDuty | X-PagerDuty-Signature: v1=… (V3 webhook subscriptions) |
| Sentry | Sentry-Hook-Signature (integration webhooks, with the integration’s client secret) |
| Linear | Linear-Signature |
| Jira | X-Hub-Signature: sha256=… (webhooks with a secret) |
| Azure Boards | Basic authentication with the secret as the password (Azure DevOps service hooks, Web Hooks) |
Signed timestamps older than 5 minutes are refused. A generic body’s id (or a MergeHarbor-Event-Id header) makes a resend run only once; title, url, service, severity and frames (a list of {"path": …}) are read by the incident and triage actions.
Chat keywords
Keyword triggers fire on messages that mention MergeHarbor in a channel mapped in the Slack, Microsoft Teams or Google Chat app. MergeHarbor does not read other channel messages, so it needs no extra permissions.