{
  "fixes": {
    "slug": "inngest",
    "name": "Inngest",
    "listing": "https://www.anchorterminal.com/tools/inngest",
    "markdown": "# Fix list: Inngest\n\nFrom Anchor Terminal's listing at https://www.anchorterminal.com/tools/inngest, the October 2026 research run, assessed 1 October 2026. Grade B, 66.3 out of 100.\n\nThis is everything the published grade says the listing lacks, the biggest possible gain to the total first. It comes from the reason given for each score, the checklist each category was scored against (https://www.anchorterminal.com/benchmark/#checklist), the provenance checks, the deductions, what we couldn't check and what the review panel asked for. A fix counts at the next check, once it's public.\n\nFor a coding agent working on Inngest: work through the items below in the product, its docs and its public pages. Each category gives the reason for its score, with the points each checklist item earned, and the checklist itself, so the gap is the items that earned less than their points. Change the product, not the wording, and keep a note of what you changed and where it's published.\n\n## 1. Reliability, 57 out of 100, up to 8.6 more on the total\n\nWhy it scored 57: Status page at status.inngest.com (incident.io) with component history (20). The history lists 16 incidents between 7 July and 26 September, most of them delayed or degraded function execution. On 16 July checkpoints and signals saw raised errors for several hours, and on 7 July function execution was down for a subset of customers. The page shows function execution at 99.14 per cent uptime. That's more than one major and less than a run of full outages, so 5 of 30. Plan limits are published with numbers (concurrency, queue depth, event size, 5,000 events per send), but no request rate for the event or REST API (10 of 15). The OpenAPI spec documents 429 on `/events` and invoke, event IDs deduplicate for 24 hours and functions take idempotency keys, with no Retry-After guidance found (12 of 15). No SLA found on the pricing page (0). `step.waitForEvent()`, `step.waitForSignal()` and the Cloud MCP are GA (10).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-reliability):\n\nHosted APIs, MCP servers, models and platforms.\n\n- 20, a public status page with component history (Statuspage, Instatus, BetterStack or the vendor's own).\n- 0 to 30, the incident record for the last 90 days on that page. 30 for a clean record or trivial incidents only, 20 for minor incidents only, 10 for one major outage (an hour or more of a core API down, or errors across the board), 0 for several. 5 when there's no history we could read, and the note says so.\n- 15, rate limits documented with numbers.\n- 15, documented 429 or overload handling (Retry-After, backoff guidance), and idempotency keys or safe-retry guidance where writes are involved.\n- 10, an SLA published for any paid tier.\n- 10, the surface agents use is generally available, not beta or preview.\n\nLocal packages, SDKs, frameworks and stdio MCP servers.\n\n- 20, installs from an official package with supported runtimes stated.\n- 25, a public CI and test suite, passing on the default branch.\n- 0 to 25, open crash or regression issues relative to activity (25 for few and handled, 0 for many, old and unanswered).\n- 15, semver discipline and breaking changes called out in a changelog.\n- 15, version 1.0 or later, or declared stable.\n\nProtocols are read from their reference implementations, the public facilitators or servers, spec stability and test vectors.\n\n## 2. Payments \u0026 pricing, 40 out of 100, up to 7.5 more on the total\n\nWhy it scored 40: No machine payment protocol (0). Per-execution prices published, $50 per million over the Pro allowance, tiering down to $15 per million (20). Free plan of 50,000 executions a month with no card (20). A person signs up in the browser for Cloud (0). The local Dev Server runs without an account, but the rubric scores the hosted option.\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-payments):\n\nThe published rubric, also on the [x402 page](https://www.anchorterminal.com/x402/).\n\n- 40, a machine payment protocol (x402, MPP or L402) on the tool's own endpoints. 10 to 30 when it covers only some endpoints or only goes through a third party, and the note says which.\n- 20, per-call or per-unit pricing published without a login. 10 for public plan-only pricing, 0 for \"contact sales\" or prices behind a login.\n- 20, a free tier or trial that doesn't need a card.\n- 20, autonomous onboarding, meaning an agent can get access without a person signing up in a browser (keyless use, x402, a programmatic key API).\n\nPayment platforms and agent wallets rarely charge for their own API over a machine protocol, so the first line has steps for them, and the highest one that applies counts. 40 when x402, MPP or L402 runs on all their own endpoints, 30 when it runs on part of their own API, 25 when their merchants can accept one, 20 for running a facilitator, 15 for paying as a buyer, and 0 when the only protocol is their own. Merchant acceptance sits above a facilitator because the platform's own customers can charge agents through it, while a facilitator settles for sellers who wire up the protocol themselves. The counter-argument (a facilitator does more for the protocol as a whole) has a point. Each note says which step applied.\n\nOpen-source software you run yourself is scored on its hosted or paid option if it has one. A free, self-hosted package with nothing to buy gets 20, 20 and 20 for the last three lines, and 0 to 40 for the first only if it ships a payment protocol.\n\n## 3. Security \u0026 auth, 60 out of 100, up to 7 more on the total\n\nWhy it scored 60: Separate event keys, signing keys and `sk-inn-api` API keys per environment (20), less 5 because the environment-wide event key travels in the URL path of `inn.gs/e/\u003ckey\u003e` (a path secret lands in the same logs a query string does, so we departed from the query-string wording of the rule; a per-request capability URL scoped to one wait gets no deduction). 15 of 30. Key types split sending events from managing the account, and RBAC is on Enterprise (10 of 20). It returns your own run data and the payload of the answering event (10). Run traces kept 24 hours on Free up to 90 days on Enterprise, audit trails on Enterprise only (8 of 15). SOC 2 Type II, a paid bounty for qualifying reports, a security@ address with an age key, yearly penetration tests and a SECURITY.md. No security.txt at www.inngest.com (17 of 20).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-security):\n\n- 0 to 30, the credential model. 30 for OAuth 2.1 with scopes, or scoped and revocable keys with rotation. 20 for plain revocable API keys. 10 for one all-powerful key. 10 off when a secret can travel in a URL query string as a documented option.\n- 0 to 20, read-only or least-privilege modes, and confirmation or approval for destructive actions.\n- 0 to 15, prompt-injection posture where the tool returns untrusted content (documented mitigations or guidance). A tool that returns no untrusted content gets 10.\n- 0 to 15, audit logs or per-call visibility for the operator.\n- 0 to 20, a security programme. security.txt or a disclosure policy, a bug bounty, SOC 2 or ISO 27001, advisories handled in public.\n\nModels are read for retention, whether API data trains models (and whether that's off by default), zero-retention options and certifications. Frameworks for telemetry defaults, approval hooks, guardrails and sandboxing.\n\n## 4. Agent ergonomics, 76 out of 100, up to 3.9 more on the total\n\nWhy it scored 76: The Cloud MCP has 33 tools (5), while REST v2 responses can be sized with cursor pagination and optional output (20). We average the two surfaces to 12 of 25. Runs list with app, function, status and time filters (20). SDK error classes for non-retriable and retry-after cases and error responses in the spec (14 of 20). Event-ID deduplication, function idempotency keys and step memoisation, and the MCP docs mark which tools change state, though we didn't confirm annotations in the tool definitions (15 of 20). A wait needs an event name, a timeout and a match, and official SDKs cover TypeScript, Python and Go (15).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-ergonomics):\n\n- 0 to 25, context cost. For MCP, the number and size of the tool definitions (25 for ten or fewer compact tools, 15 for 11 to 30, 5 for more than 30, plus up to 10 back for toolsets, dynamic loading or read-only subsets). For APIs, whether responses can be sized (field selection, limits, summaries).\n- 20, pagination, filtering and output-size controls.\n- 20, actionable, documented error responses, codes and messages an agent can recover from.\n- 20, idempotency or safe retries, and for MCP the `readOnlyHint` and `destructiveHint` annotations.\n- 15, sensible defaults, few required parameters, and official SDKs in at least two languages.\n\nModels are read for tool use, structured output, prompt caching, context length, batch and SDKs. Frameworks for how much code and how many defaults a tool-calling agent with MCP needs.\n\n## 5. Transparency \u0026 trust, 56 out of 100, up to 3.9 more on the total\n\nMade of editorial 52, provenance 60.\n\nWhy it scored 56: Server under the SSPL with delayed Apache-2.0 publication, which isn't an OSI licence, and Apache-2.0 SDKs (20 of 30). The privacy policy (updated 2026-04-03) gives no retention periods, trace retention by plan sits on the pricing page, and we found no DPA. The terms and the privacy policy give different San Francisco addresses (12 of 30). Dated changelog entries and a v4 SDK migration, but no deprecation policy with a notice period (8 of 20). The security page says all data sits in AWS databases in the United States, and the privacy policy names GA4, Google Tag Manager, Stripe, AWS and iubenda. No full subprocessor list we could read (12 of 20).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-transparency):\n\n- 0 to 30, source availability and licence clarity. 30 for open source under an OSI licence, 15 for closed with clear terms, 0 for unclear terms.\n- 0 to 30, data handling and retention statements that agree with each other (privacy policy, DPA, retention periods, subprocessors).\n- 0 to 20, a deprecation policy or notices with dates.\n- 0 to 20, telemetry disclosed with an opt-out (local software), or subprocessors and data locations disclosed (hosted).\n\nThe other half of Transparency and trust is the provenance score, computed from checked facts (below). The category score is the mean of the two.\n\nProvenance checks not met in full (half of this category, computed from checked facts):\n\n- Domain age: inngest.com, no registry record we could read (0 of 15)\n- Endpoint on the vendor's domain: inn.gs is not on inngest.com (0 of 15)\n- security.txt: not found (0 of 10)\n\n## 6. Schema \u0026 documentation, 89 out of 100, up to 1.8 more on the total\n\nWhy it scored 89: OpenAPI 3.0.3 for REST API v2, 35 paths, at api-docs.inngest.com/api-specs/v2.json (25). llms.txt on the main site and the API docs, plus llms-full.txt and a .md copy of each API page (10). The wait docs say when to use `waitForSignal` instead of `waitForEvent` and spell out the race where an early answer is missed (15 of 20). Typed SDKs in TypeScript, Python and Go. The `if` match is a CEL string (12 of 15). Many code examples and 429 and error responses in the spec (12 of 15). Dated changelog, release notes that flag breaking changes, and versioned v1 and v2 APIs (15).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-schema):\n\nAPIs and MCP servers.\n\n- 25, a machine-readable contract (a public OpenAPI file or similar; for MCP, typed JSON Schema inputs on every tool).\n- 10, llms.txt or Markdown docs served for agents.\n- 0 to 20, descriptions that say what a tool is for, when to use it and when not to, read from the tool definitions in the source or the API reference.\n- 0 to 15, typed inputs with enums, constraints and required fields, and no free-form JSON blobs.\n- 0 to 15, examples and documented error responses.\n- 15, versioning and a public changelog.\n\nModels are read from the API reference, the OpenAPI file, llms.txt, the structured-output and tool-use docs and the model cards. Frameworks from docs a model can follow, typed interfaces, examples and the API reference.\n\n## 7. Maintenance \u0026 community, 88 out of 100, up to 1.1 more on the total\n\nWhy it scored 88: TypeScript SDK 4.21.0 on 2026-09-22 (30). Server releases v1.35.0 to v1.41.1 between 7 July and 5 August, eight in all (20). The server repository has 55 open issues and 182 open pull requests, and we didn't sample reply times (15 of 25). Current official SDKs in TypeScript, Python and Go (15). CI badge on main and a Node 20 floor (8 of 10).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-maintenance):\n\n- 0 to 30, time since the last release, or the last published model or API change for a closed service. 30 within 30 days, 20 within 90, 10 within 180, 0 older.\n- 20, at least three releases or dated changelog entries in the last 90 days.\n- 0 to 25, responsiveness. Issues and pull requests answered on GitHub (the open issues and how recent the replies are). For closed services, a public changelog and a support or community channel that answers, 0 to 15.\n- 15, presence in the official MCP registry under a verified namespace (MCP servers), or current official SDKs (APIs and models).\n- 10, package health, current dependencies and CI.\n\nModels are read for deprecation notice periods and model churn rather than release counts.\n\n## What we couldn't check\n\nWhat we couldn't read counted as absent. Publishing it on a page a plain HTTP fetch can read (not only in a browser) lets the next check count it.\n\n- Whether any plan carries an uptime SLA. The pricing page we read didn't state one.\n- The window behind the 99.14 per cent function execution figure on the status page.\n- Whether the Cloud MCP sets `readOnlyHint` and `destructiveHint` in its tool definitions.\n- Whether the 7-day sleep cap on Free from last week's check still applies. The usage-limits page now ties waits to run length.\n\n## Weaknesses\n\n- No reviewer inbox, Slack app or email, so the human side is your code\n- An answer sent before `waitForEvent` starts listening isn't matched\n- 16 incidents on the status page between 7 July and 26 September, with function execution at 99.14 per cent\n- Audit trails, RBAC and SAML only on Enterprise, and traces kept 24 hours on Free\n- Server under the SSPL, which isn't an OSI licence\n\n## What costs an agent a turn today\n\nThe notes we give agents before they call it. Each one is a workaround an agent shouldn't need.\n\n- Use `step.waitForSignal()` when one run waits for one answer, and `waitForEvent` only when one answer resumes many runs\n- Register the wait before you send the approval request, or check the external state first, since early events are missed\n- Use a unique approval ID per tool call and `match` on it, so parallel approvals resolve independently\n- Treat `null` or `undefined` as a timeout and decide on purpose whether that rejects, approves or escalates\n- Set an event `id` when sending the answer, so a retried send is dropped within 24 hours\n\n## What the review panel asked for\n\n- a deprecation notice period\n- header-based event keys\n- approver identity on resume\n\n## When it's done\n\nSend what changed and where it's published as a dispute (https://www.anchorterminal.com/builders/#disputes, or `POST https://www.anchorterminal.com/api/v1/contact` with `\"kind\": \"dispute\"`). Disputes are answered in public, and the listing is checked again by the same checklist. Paying for an audit or a listing claim changes nothing here.\n",
    "grade": "B",
    "score": 66.3,
    "assessed": "2026-10-01",
    "run": "October 2026 research run",
    "categories": [
      {
        "key": "reliability",
        "name": "Reliability",
        "score": 57,
        "maxGain": 8.6,
        "reason": "Status page at status.inngest.com (incident.io) with component history (20). The history lists 16 incidents between 7 July and 26 September, most of them delayed or degraded function execution. On 16 July checkpoints and signals saw raised errors for several hours, and on 7 July function execution was down for a subset of customers. The page shows function execution at 99.14 per cent uptime. That's more than one major and less than a run of full outages, so 5 of 30. Plan limits are published with numbers (concurrency, queue depth, event size, 5,000 events per send), but no request rate for the event or REST API (10 of 15). The OpenAPI spec documents 429 on `/events` and invoke, event IDs deduplicate for 24 hours and functions take idempotency keys, with no Retry-After guidance found (12 of 15). No SLA found on the pricing page (0). `step.waitForEvent()`, `step.waitForSignal()` and the Cloud MCP are GA (10).",
        "checklist": [
          "Hosted APIs, MCP servers, models and platforms.",
          "- 20, a public status page with component history (Statuspage, Instatus, BetterStack or the vendor's own).\n- 0 to 30, the incident record for the last 90 days on that page. 30 for a clean record or trivial incidents only, 20 for minor incidents only, 10 for one major outage (an hour or more of a core API down, or errors across the board), 0 for several. 5 when there's no history we could read, and the note says so.\n- 15, rate limits documented with numbers.\n- 15, documented 429 or overload handling (Retry-After, backoff guidance), and idempotency keys or safe-retry guidance where writes are involved.\n- 10, an SLA published for any paid tier.\n- 10, the surface agents use is generally available, not beta or preview.",
          "Local packages, SDKs, frameworks and stdio MCP servers.",
          "- 20, installs from an official package with supported runtimes stated.\n- 25, a public CI and test suite, passing on the default branch.\n- 0 to 25, open crash or regression issues relative to activity (25 for few and handled, 0 for many, old and unanswered).\n- 15, semver discipline and breaking changes called out in a changelog.\n- 15, version 1.0 or later, or declared stable.",
          "Protocols are read from their reference implementations, the public facilitators or servers, spec stability and test vectors."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-reliability"
      },
      {
        "key": "payments",
        "name": "Payments \u0026 pricing",
        "score": 40,
        "maxGain": 7.5,
        "reason": "No machine payment protocol (0). Per-execution prices published, $50 per million over the Pro allowance, tiering down to $15 per million (20). Free plan of 50,000 executions a month with no card (20). A person signs up in the browser for Cloud (0). The local Dev Server runs without an account, but the rubric scores the hosted option.",
        "checklist": [
          "The published rubric, also on the [x402 page](https://www.anchorterminal.com/x402/).",
          "- 40, a machine payment protocol (x402, MPP or L402) on the tool's own endpoints. 10 to 30 when it covers only some endpoints or only goes through a third party, and the note says which.\n- 20, per-call or per-unit pricing published without a login. 10 for public plan-only pricing, 0 for \"contact sales\" or prices behind a login.\n- 20, a free tier or trial that doesn't need a card.\n- 20, autonomous onboarding, meaning an agent can get access without a person signing up in a browser (keyless use, x402, a programmatic key API).",
          "Payment platforms and agent wallets rarely charge for their own API over a machine protocol, so the first line has steps for them, and the highest one that applies counts. 40 when x402, MPP or L402 runs on all their own endpoints, 30 when it runs on part of their own API, 25 when their merchants can accept one, 20 for running a facilitator, 15 for paying as a buyer, and 0 when the only protocol is their own. Merchant acceptance sits above a facilitator because the platform's own customers can charge agents through it, while a facilitator settles for sellers who wire up the protocol themselves. The counter-argument (a facilitator does more for the protocol as a whole) has a point. Each note says which step applied.",
          "Open-source software you run yourself is scored on its hosted or paid option if it has one. A free, self-hosted package with nothing to buy gets 20, 20 and 20 for the last three lines, and 0 to 40 for the first only if it ships a payment protocol."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-payments"
      },
      {
        "key": "security",
        "name": "Security \u0026 auth",
        "score": 60,
        "maxGain": 7,
        "reason": "Separate event keys, signing keys and `sk-inn-api` API keys per environment (20), less 5 because the environment-wide event key travels in the URL path of `inn.gs/e/\u003ckey\u003e` (a path secret lands in the same logs a query string does, so we departed from the query-string wording of the rule; a per-request capability URL scoped to one wait gets no deduction). 15 of 30. Key types split sending events from managing the account, and RBAC is on Enterprise (10 of 20). It returns your own run data and the payload of the answering event (10). Run traces kept 24 hours on Free up to 90 days on Enterprise, audit trails on Enterprise only (8 of 15). SOC 2 Type II, a paid bounty for qualifying reports, a security@ address with an age key, yearly penetration tests and a SECURITY.md. No security.txt at www.inngest.com (17 of 20).",
        "checklist": [
          "- 0 to 30, the credential model. 30 for OAuth 2.1 with scopes, or scoped and revocable keys with rotation. 20 for plain revocable API keys. 10 for one all-powerful key. 10 off when a secret can travel in a URL query string as a documented option.\n- 0 to 20, read-only or least-privilege modes, and confirmation or approval for destructive actions.\n- 0 to 15, prompt-injection posture where the tool returns untrusted content (documented mitigations or guidance). A tool that returns no untrusted content gets 10.\n- 0 to 15, audit logs or per-call visibility for the operator.\n- 0 to 20, a security programme. security.txt or a disclosure policy, a bug bounty, SOC 2 or ISO 27001, advisories handled in public.",
          "Models are read for retention, whether API data trains models (and whether that's off by default), zero-retention options and certifications. Frameworks for telemetry defaults, approval hooks, guardrails and sandboxing."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-security"
      },
      {
        "key": "ergonomics",
        "name": "Agent ergonomics",
        "score": 76,
        "maxGain": 3.9,
        "reason": "The Cloud MCP has 33 tools (5), while REST v2 responses can be sized with cursor pagination and optional output (20). We average the two surfaces to 12 of 25. Runs list with app, function, status and time filters (20). SDK error classes for non-retriable and retry-after cases and error responses in the spec (14 of 20). Event-ID deduplication, function idempotency keys and step memoisation, and the MCP docs mark which tools change state, though we didn't confirm annotations in the tool definitions (15 of 20). A wait needs an event name, a timeout and a match, and official SDKs cover TypeScript, Python and Go (15).",
        "checklist": [
          "- 0 to 25, context cost. For MCP, the number and size of the tool definitions (25 for ten or fewer compact tools, 15 for 11 to 30, 5 for more than 30, plus up to 10 back for toolsets, dynamic loading or read-only subsets). For APIs, whether responses can be sized (field selection, limits, summaries).\n- 20, pagination, filtering and output-size controls.\n- 20, actionable, documented error responses, codes and messages an agent can recover from.\n- 20, idempotency or safe retries, and for MCP the `readOnlyHint` and `destructiveHint` annotations.\n- 15, sensible defaults, few required parameters, and official SDKs in at least two languages.",
          "Models are read for tool use, structured output, prompt caching, context length, batch and SDKs. Frameworks for how much code and how many defaults a tool-calling agent with MCP needs."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-ergonomics"
      },
      {
        "key": "transparency",
        "name": "Transparency \u0026 trust",
        "score": 56,
        "maxGain": 3.9,
        "reason": "Server under the SSPL with delayed Apache-2.0 publication, which isn't an OSI licence, and Apache-2.0 SDKs (20 of 30). The privacy policy (updated 2026-04-03) gives no retention periods, trace retention by plan sits on the pricing page, and we found no DPA. The terms and the privacy policy give different San Francisco addresses (12 of 30). Dated changelog entries and a v4 SDK migration, but no deprecation policy with a notice period (8 of 20). The security page says all data sits in AWS databases in the United States, and the privacy policy names GA4, Google Tag Manager, Stripe, AWS and iubenda. No full subprocessor list we could read (12 of 20).",
        "blend": "editorial 52, provenance 60",
        "checklist": [
          "- 0 to 30, source availability and licence clarity. 30 for open source under an OSI licence, 15 for closed with clear terms, 0 for unclear terms.\n- 0 to 30, data handling and retention statements that agree with each other (privacy policy, DPA, retention periods, subprocessors).\n- 0 to 20, a deprecation policy or notices with dates.\n- 0 to 20, telemetry disclosed with an opt-out (local software), or subprocessors and data locations disclosed (hosted).",
          "The other half of Transparency and trust is the provenance score, computed from checked facts (below). The category score is the mean of the two."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-transparency"
      },
      {
        "key": "schema",
        "name": "Schema \u0026 documentation",
        "score": 89,
        "maxGain": 1.8,
        "reason": "OpenAPI 3.0.3 for REST API v2, 35 paths, at api-docs.inngest.com/api-specs/v2.json (25). llms.txt on the main site and the API docs, plus llms-full.txt and a .md copy of each API page (10). The wait docs say when to use `waitForSignal` instead of `waitForEvent` and spell out the race where an early answer is missed (15 of 20). Typed SDKs in TypeScript, Python and Go. The `if` match is a CEL string (12 of 15). Many code examples and 429 and error responses in the spec (12 of 15). Dated changelog, release notes that flag breaking changes, and versioned v1 and v2 APIs (15).",
        "checklist": [
          "APIs and MCP servers.",
          "- 25, a machine-readable contract (a public OpenAPI file or similar; for MCP, typed JSON Schema inputs on every tool).\n- 10, llms.txt or Markdown docs served for agents.\n- 0 to 20, descriptions that say what a tool is for, when to use it and when not to, read from the tool definitions in the source or the API reference.\n- 0 to 15, typed inputs with enums, constraints and required fields, and no free-form JSON blobs.\n- 0 to 15, examples and documented error responses.\n- 15, versioning and a public changelog.",
          "Models are read from the API reference, the OpenAPI file, llms.txt, the structured-output and tool-use docs and the model cards. Frameworks from docs a model can follow, typed interfaces, examples and the API reference."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-schema"
      },
      {
        "key": "maintenance",
        "name": "Maintenance \u0026 community",
        "score": 88,
        "maxGain": 1.1,
        "reason": "TypeScript SDK 4.21.0 on 2026-09-22 (30). Server releases v1.35.0 to v1.41.1 between 7 July and 5 August, eight in all (20). The server repository has 55 open issues and 182 open pull requests, and we didn't sample reply times (15 of 25). Current official SDKs in TypeScript, Python and Go (15). CI badge on main and a Node 20 floor (8 of 10).",
        "checklist": [
          "- 0 to 30, time since the last release, or the last published model or API change for a closed service. 30 within 30 days, 20 within 90, 10 within 180, 0 older.\n- 20, at least three releases or dated changelog entries in the last 90 days.\n- 0 to 25, responsiveness. Issues and pull requests answered on GitHub (the open issues and how recent the replies are). For closed services, a public changelog and a support or community channel that answers, 0 to 15.\n- 15, presence in the official MCP registry under a verified namespace (MCP servers), or current official SDKs (APIs and models).\n- 10, package health, current dependencies and CI.",
          "Models are read for deprecation notice periods and model churn rather than release counts."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-maintenance"
      }
    ],
    "provenance": [
      {
        "label": "Domain age",
        "value": "inngest.com, no registry record we could read",
        "points": 0,
        "max": 15
      },
      {
        "label": "Endpoint on the vendor's domain",
        "value": "inn.gs is not on inngest.com",
        "points": 0,
        "max": 15
      },
      {
        "label": "security.txt",
        "value": "not found",
        "points": 0,
        "max": 10
      }
    ],
    "unchecked": [
      "Whether any plan carries an uptime SLA. The pricing page we read didn't state one.",
      "The window behind the 99.14 per cent function execution figure on the status page.",
      "Whether the Cloud MCP sets `readOnlyHint` and `destructiveHint` in its tool definitions.",
      "Whether the 7-day sleep cap on Free from last week's check still applies. The usage-limits page now ties waits to run length."
    ],
    "weaknesses": [
      "No reviewer inbox, Slack app or email, so the human side is your code",
      "An answer sent before `waitForEvent` starts listening isn't matched",
      "16 incidents on the status page between 7 July and 26 September, with function execution at 99.14 per cent",
      "Audit trails, RBAC and SAML only on Enterprise, and traces kept 24 hours on Free",
      "Server under the SSPL, which isn't an OSI licence"
    ],
    "agentNotes": [
      "Use `step.waitForSignal()` when one run waits for one answer, and `waitForEvent` only when one answer resumes many runs",
      "Register the wait before you send the approval request, or check the external state first, since early events are missed",
      "Use a unique approval ID per tool call and `match` on it, so parallel approvals resolve independently",
      "Treat `null` or `undefined` as a timeout and decide on purpose whether that rejects, approves or escalates",
      "Set an event `id` when sending the answer, so a retried send is dropped within 24 hours"
    ],
    "requests": [
      {
        "text": "a deprecation notice period",
        "reviews": 1
      },
      {
        "text": "header-based event keys",
        "reviews": 1
      },
      {
        "text": "approver identity on resume",
        "reviews": 1
      }
    ],
    "recheck": "https://www.anchorterminal.com/builders/#disputes"
  },
  "meta": {
    "attribution": "Anchor Terminal (https://www.anchorterminal.com)",
    "docs": "https://www.anchorterminal.com/docs/",
    "generatedAt": "2026-10-04",
    "license": "CC-BY-4.0",
    "method": "https://www.anchorterminal.com/benchmark/",
    "methodology": "0.3",
    "openapi": "https://www.anchorterminal.com/openapi.json",
    "preview": false,
    "run": "2026-10-01",
    "runLabel": "October 2026 research run"
  }
}