Service status, as recorded.

Recorded release

The version id is the one Cloudflare assigned to the Worker deployment. The deployment time is the moment that version reached 100% of traffic. The source commit is the commit on the main branch the deploying checkout was at, with a clean tree, when the deploy ran.

How the command count was produced

The number above comes from a deployed-bundle count. The parity gate on the source commit counted 73 authenticated command definitions, and the Worker script downloaded from Cloudflare after the deploy is byte-identical to the bundle built from that commit. No authenticated tools/list or GET /v1/commands readback of this version has been recorded.

Here is what that means. The service registers its MCP tools, REST commands and CLI commands from one shared registry, and a parity gate in the repository counts the authenticated command definitions in that registry. After the deploy, the Worker script was downloaded back from Cloudflare and compared byte for byte with the bundle built from the source commit. The two matched, so the count describes the code that is serving traffic. It does not describe a fresh listing returned by the live endpoint to an authenticated client. That readback is yours to run, and the verification section shows how.

The MCP backlink tool catalog is built from the same registry and shows each tool in its recorded state. Its counts and this page’s count come from the same file, so they agree by construction; neither one is a measurement of the live endpoint.

Live health check

The service answers an anonymous health route at https://app.agentlinkops.com/healthz. It returns a small JSON object with the fields service, environment, status, version. A response with "status": "ok" means the Worker received the request and answered it. It says nothing about the database, the check scheduler or any other component behind the route. Nothing on this page reads that route for you, and no result from it is recorded here.

Two field values are worth knowing before you compare them with this page. The version field is the application’s fixed version string, which is a different value from the Cloudflare deployment id in the table above. The service field still returns the internal Worker name linktrail until DP-0029-T07 renames the Worker; that name is a compatibility identifier, and the product is AgentLinkOps.

Documentation release digest

The documentation site publishes its own machine-readable release record at https://docs.agentlinkops.com/release.json. It names the deployment the documentation was generated against, the evidence kind behind that deployment, and the tool names read back at the time. That file and this page are regenerated by different releases, so they can name different versions for a while. When they disagree, the later of the two deployment times is the newer record, and the receipt each one names is where the difference is explained.

Verify this yourself

Each recorded fact above has a call that checks it. The first two need no account. The last two need an invited workspace, because the command catalog is served only to an authenticated principal.

1. Health route. Confirms the service answers at the recorded origin.

   curl -sS https://app.agentlinkops.com/healthz

2. Documentation release digest. Shows the version the documentation was built against, for comparison with the table above.

   curl -sS https://docs.agentlinkops.com/release.json

3. Authenticated MCP tool listing. With a connected client, ask for the tool list and count the names. In Claude Code, add the server and then ask the agent to run tools/list and report the count; the setup command and the OAuth approval are described in connect your agent. The names your client returns are the ones to trust; a difference from the recorded count means the deployment or the registry has moved since this page was generated.

   claude mcp add --transport http agentlinkops https://app.agentlinkops.com/mcp
   # then, in the session: list the AgentLinkOps tools and tell me how many there are

4. REST command catalog. The same registry over HTTP. Create a scoped API key in your workspace under Agent access, keep it in your tool’s secret storage, and send it as a bearer header. The response is an object with an items array; its length is the live command count for your credential.

   curl -sS -H "Authorization: Bearer $AGENTLINKOPS_API_KEY" https://app.agentlinkops.com/v1/commands | jq '.items | length'

Every call above is a read. None of them creates a watch, starts a check or changes a workspace.

What this page does not say

• No availability percentage. Nothing measures availability yet, so no figure appears here or anywhere else on the site.
• No incident history. There is no incident record to publish, and an empty list would imply one was kept.
• No live result. The health route is described so you can run it. This page did not run it for you and stores no answer.
• No promise about the next release. The values above describe one deployment on one date.

The reasoning behind those omissions is on what your agent can prove to you: a schedule in the code proves scheduling exists, and a percentage without a measurement behind it would be a claim the product cannot back. Who can reach the deployed service today, and what its credentials permit, is on the access and data page; how its checks are decided is on the methodology page.

How this page is regenerated

This page is regenerated with each site release and shows the values recorded at that release. The values live in one small data file in the site source, refreshed from the production release receipt before the site is rebuilt. A release of the hosted service without a matching site release leaves this page describing the previous version until the next rebuild. That is why the recorded date is printed at the top.

Recorded September 16, 2026 from version ab91d0a1. If the health route or an authenticated listing disagrees with this page, the endpoint is right and the page is stale.