Troubleshooting invocations
Why an invocation didn't run, ran silently, or errored: the three-step triage and the fix for each doorway.
Something should have fired and didn't, or fired and you never heard about it. Most of the time the answer is one of three things, so start with the triage before digging into a specific doorway.
Most silent invocations are paused, filtered, or quiet on purpose
Check the invocation's status first, then whether a run actually started, then whether it ran and chose silence. That order resolves most cases in under a minute.
Check these three things first
Is the invocation still active?
Invocations pause themselves in specific, deliberate cases: a schedule whose creator left the workspace, a Live watch after three consecutive failed checks, an email address whose owner departed, a webhook endpoint you paused. A schedule with no future occurrences marks itself completed. Check the status where you configured it.
Did a run start?
Every doorway keeps its own log: Run History on schedules and Live Mode, Recent Emails on an email address, Recent invocations on a webhook endpoint, the thread itself for Slack, Telegram, and MCP. If there's a run, the problem is downstream; if there isn't, the trigger never got through.
Did it run and stay quiet on purpose?
Alert schedules and Live Mode suppress the all-clear: the run appears in history as nothing to report, and that's success. A run that finished but couldn't deliver records a delivery warning on the schedule instead of failing.
A schedule didn't fire
Occurrences never overlap: if the previous run was still going, the new occurrence was deferred, not lost. Missed occurrences skip rather than backfill, so a schedule paused for two weeks resumes at its next occurrence with no catch-up burst. In continue mode, a run also waits while a person is actively using the target thread. If runs are landing but the report goes to the wrong place, remember delivery is snapshotted at run start: mid-run edits apply from the next occurrence. Details in Schedules.
Live Mode is silent or paused
Silence is usually the product working: an all-clear check delivers nothing and logs nothing to report. A paused watch hit three consecutive error-severity checks, which means the check itself couldn't run (a missing integration, a failing tool), not that it found problems; fix the cause and resume, which resets the streak. Live · check delivery means checks run fine but a recent alert couldn't be delivered, so reconnect the channel. Details in Live Mode.
Slack doesn't respond
Check the trigger mode first: on mentions-only, plain channel messages are ignored by design. If the agent went silent everywhere at once, an identity change is the usual cause, because changing an agent's Slack identity disables its channel configurations until each one is re-enabled. And a bot can only see channels it has been added to. The full setup is in Slack.
Telegram doesn't respond
Work down the gate list: DMs answer only the paired owner, so an unpaired bot answers no one. In groups, being added is not authorization; the owner has to send /authorize in the group, and the response trigger still filters what counts. If mentions or plain messages never arrive, Telegram's privacy mode is eating them before Hyperagent ever sees them: disable it in BotFather and re-add the bot. A bot that stopped responding entirely may have a revoked token or a user who blocked it, both of which surface as warnings. Details in Telegram.
An email didn't trigger the agent
Rejections are silent by design, so the sender never gets a bounce and you never get an error. The message was dropped if the sender didn't match the Allowed Senders list, failed email authentication, was flagged as spam or a virus, or exceeded the size cap. Check Recent Emails on the address: if the message isn't listed, it was rejected before reaching the agent. Details in Email.
A webhook call errored
The status code says exactly where it stopped:
| Code | What it means |
|---|---|
401 / 403 | Missing or wrong secret. Send it in the X-Hyperagent-Webhook-Secret header; rotate it if it's lost. |
404 | Wrong endpoint ID in the URL. |
413 | Body over the 1 MB cap. |
422 | The endpoint is paused, or the agent is archived. |
429 | Rate limited; retry after the Retry-After header. |
503 | The webhook feature is disabled for the account. |
A 202 means the call worked: webhooks are fire-and-forget, the response never contains the agent's result, and the work lands in the run's thread. Details in Webhooks.
An MCP client can't run an agent
If an agent shows up in list_agents but create_thread refuses it, the agent is set to Ask first, which can't run over MCP because there's no surface to approve its actions. A run that seems stuck usually isn't: every MCP run is asynchronous, so poll get_thread until it stops running. If the client can't connect at all, check whether its connection was revoked under Settings → MCP access; revocation is immediate. Details in MCP server.
Still stuck
Open the run's thread. Whatever the doorway, the thread holds the complete record of what the agent did, and the error messages there are specific in ways a status badge can't be.