Read the delivery log
See every attempt bynh made to send an event, send one again, and turn a connection back on after it was turned off.
3 min readUpdated
Every connection keeps a log of what bynh sent and what came back. Open the connection in Settings › Integrations to see it. Owners and admins can read the log; everyone else sees the connection’s status.
What’s logged
Each delivery shows its time, event, result and how long the other side took to answer. Open one to see each attempt, with:
- The request: its headers and body (up to 16 KB).
- The response: its status code and body (up to 4 KB).
- The event payload, which you can copy.
- The error, when it failed, and when the next try is due.
Before anything is stored, bynh removes the connection’s saved keys and anything shaped like a token, such as bearer tokens, API keys, webhook secrets and the secret part of webhook URLs. A webhook signature shows shortened. The log keeps each attempt for 90 days. Choose Failed under Show to see only what needs fixing.
| Result | Meaning |
|---|---|
| Delivered | The other side accepted it on the first try. |
| Delivered on retry | It went through after one or more retries. |
| Retrying | It failed in a way worth trying again. The next try is scheduled. |
| Failed | It failed for good, or bynh stopped trying after a day. |
| Nothing to send | There was nothing to do, such as a comment with no linked issue. |
| Collapsed | The very same message about the same thing went out to this connection in the last 2 minutes, so this one wasn’t sent. |
| Missed while off | The connection was paused or turned off when the event happened. |
| Sending | It’s on its way. |
Retries
When the other side times out, asks bynh to slow down (429) or has a problem on its side (5xx), bynh tries again: 6 tries in all over about 12 hours, with growing waits. Any other refusal, such as a revoked token or a deleted webhook, fails at once, since trying again won’t fix it. The webhooks guide gives the exact waits.
Send an event again
Open a delivery and choose Redeliver. bynh sends the same event, with the same event id and a new delivery id, and the new attempt shows at the top of the log. The connection must be on, and tests can’t be sent again; send a new test instead.
When a connection is turned off
If five deliveries in a row fail for good, bynh turns the connection off. Some failures turn it off at once, such as the bynh app being removed from GitHub or Jira access being revoked. When that happens:
- The connection shows Turned off, with the last error.
- Workspace owners get an email, and owners and admins a push notification in the bynh app, saying how to fix it.
- The audit log records why it was turned off.
- Events that happen while it’s off show in the log as Missed while off.
Step 1: Fix the cause
Read the last error. Usually a token or webhook needs replacing: choose Edit and paste a new one, or reconnect a connection you added with one click.
Step 2: Turn it back on
Choose Turn back on. bynh sends a test first and only turns the connection on if the test goes through. The failure count starts over.
Step 3: Send what you missed
Missed events aren’t replayed on their own. Find them in the log and choose Redeliver for the ones you still need.
Pause a connection
Choose Pause to stop sending for a while, such as during a migration. Events that happen while it’s paused show as Missed while off. Choose Turn back on when you’re ready; it sends a test first, the same as above.
Was this helpful?