--- title: Troubleshoot channels, stale crawls and quota category: troubleshoot summary: Fix unresolved source channels, recognize a source that has stopped publishing, and handle every limit error without hammering the API or misleading your user. order: 26 updated: 2026-10-07 next: support-handoff related: quotas-retries-and-pagination, source-channel-metadata-and-filters reference: /agent-guide.md, /pricing --- Three problems account for most of what remains after an empty window. A source channel name does not resolve. A source has stopped publishing. A call returns a limit error. Each has a clear indicator and a clear action. ## When to use this Use it in three cases. A source channel filter returns nothing. A source your user cares about goes quiet. A call returns `429`, `401` or an allowance message. ## Smallest working call Read the Stream's source channels and your usage. Both are free: ```mcp synorb-details {"stream_ids": ["STREAM_ID"], "verbosity": "standard"} ``` ```bash curl -sS https://api.synorb.com/account \ -H "Authorization: Bearer $SYNORB_KEY" ``` ## What you get back ### Unresolved source channels A `source_channel_names` value that does not match fails closed: zero Manifests and zero usage. The response carries `did_you_mean` with canonical suggestions. 1. Call `synorb-details` and copy the source channel's `name` or its `id` exactly. 2. Prefer `source_channel_ids`, passed as strings, over names. 3. Make sure the source channel belongs to the Stream you are querying. A source channel from a different Stream does not narrow this one. 4. If `unauthorized_source_broadening` appears on a Beacon run, the source channel is not in the Beacon's saved scope. `PATCH` the Beacon to add it, or run with the saved scope. ### Stale crawls A source can stop publishing for an ordinary reason, such as a quiet season. It can also stop for an operational reason, such as a site change. Tell them apart with data: | Field | Where | Meaning | | --- | --- | --- | | `freshness_state: stale` or `never_published` | Stream | The Stream has not produced recently | | `days_since_last_manifest` and `last_manifest_at` | Stream | How long it has been | | `is_active: false` | Source channel | Synorb has stopped crawling that source | | `crawl_frequency`, `avg_items_30d` | Source channel | The normal pattern of the source channel | | `source.source_reachability.status` | Manifest | The crawler's last run result for that source, for example `success`, `partial`, `empty`, `failed`, `blocked` or `rate_limited`, or `null` when the source has no registry row. It is not a live link check | If a source channel's last run is `failed`, report it. Also report it if its Stream is `stale` for much longer than its `avg_items_30d` suggests. See the support handoff guide. Do not promise that it recovers on a date. ### Limit and auth errors Route on `error_code`, not on prose. Read `detail.error_code` when it is present, then the top-level `error_code`, then the top-level `error`. The `401` key errors are top-level. The `rate_limited` and `quota_exhausted` errors are under `detail`. `demo_key_rate_limited` is top-level. Beacon run rejections are top-level, with `error_code` and `beacon_execution_status`. Other `4xx` validation errors are under `detail`. | Status and code | Meaning | Action | | --- | --- | --- | | `401 synorb_key_invalid` | The key is wrong or revoked | Use the active key from your dashboard. Mint a demo key at `/connect` only if you have no account. Do not retry the same key. | | `401 synorb_key_expired` | The 72-hour demo ended | Mint a new demo key or sign up. | | `429 rate_limited` | Too many requests | Wait for `Retry-After`, then retry with backoff. | | `429 quota_exhausted` (demo key) | The 25-Manifest demo allowance is used | Read `key_expires_at` and `starter_bind`. Bind an email. There is no `Retry-After`. | | `429` monthly exhaustion | The period's allowance is used | Wait for `quota_resets_on`, or upgrade. Tell your user. | | An MCP tool error with a usage line that shows `0 Manifests remaining` | The key has no allowance left. Over MCP even a free `count` is reported as a tool error in this state. REST returns HTTP 200 | Treat it as the exhausted-allowance case above. Do not retry. | | `429 demo_key_rate_limited` | More than 10 demo keys requested from one IP in an hour | Stop minting. Bind an email to your existing key. | | `409` invalid plan token | The body changed after planning | Plan again with the full request. | | `422 date_window_required` | A Beacon run had no window | Add `lookback_hours`, `days` or dates. | | `409 beacon_archived` | The Beacon is archived | Restore it, then run it. | | `beacon_limit_exceeded` | The plan's Beacon cap is reached | Archive one, or upgrade. | Pre-flight your allowance with `GET /account`: `usage.manifests_used`, `usage.manifests_remaining` and `usage.beacons_used`. Zero-usage calls never move them. Synorb does not bill a Manifest you already received again inside the dedup window. ## Failure modes | Symptom | Cause | What to do | | --- | --- | --- | | A retry loop that never ends | You retried a `4xx` or a `quota_exhausted` | Retry only `rate_limited` and transient `5xx`. | | Usage dropping faster than expected | A broad scope, or a large `target_count` | Count first, narrow, and lower `target_count`. | | A source channel filter works on one Stream but not another | The source channel is not part of the second Stream | Use the source channel from that Stream's own list. | | You cannot tell stale from quiet | You looked at only one field | Compare `avg_items_30d` with `days_since_last_manifest`. | | The key stops working after a rotation | Issuing a new key revokes the old one | Use the key the dashboard shows as active. | ## Make it good for your user Never blame the user for a limit, and never hide it. "You have used the 25 items in this demo. If you verify your email, I can keep going on the same key. It is free, with 100 a month." That one sentence explains the limit, names the cheapest fix and keeps your user moving. For a stale source, say what you found and what you will watch: "This source has not posted in 12 days, which is longer than usual. I will note it and keep checking." ## Next guide [Write a useful support handoff](/agent-resources/support-handoff): what to collect, what to redact, and how to ask for help.