Telemetry

backmesh plans are priced by jobs started over a rolling 30 days. To count them, the listener in your install sends one small event per job to api.backmesh.com. This page lists everything it sends.

What’s sent

Each event describes one job’s runner, never the job itself:

Field	What it is
`id`	SHA-256 of your org’s ID and GitHub’s job ID, so a resent event counts once
`version`	The backmesh version
`started_at`	When the job started
`cloud`	`aws`, `gcp` or `azure`
`region`	The cloud region the runner ran in
`vm_type`	The VM type, such as `m7a.4xlarge`
`pool`	The backmesh pool’s name
`capacity`	`spot` or `on-demand`
`label`	The runner label the job asked for, such as `backmesh-4`
`queued_ms`	From GitHub queuing the job to assigning a runner, by GitHub’s clock
`boot_ms`	How long the runner took to start (`null` until the listener measures it)
`features`	backmesh features turned on, such as retrying on demand

A field the listener doesn’t know yet is null. Your org and install aren’t fields: the Worker reads them from your install’s sign-in, made once with GitHub during backmesh install. The listener sends events in batches, such as:

{
  "events": [
    {
      "id": "5f0c6a4c1b8e2d3f9a7e6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7c6d5e",
      "version": "0.1.7",
      "started_at": "2026-11-06T14:03:27Z",
      "cloud": "aws",
      "region": "us-east-2",
      "vm_type": "m7a.4xlarge",
      "pool": "bm-aws-spot",
      "capacity": "spot",
      "label": "backmesh-4",
      "queued_ms": 2100,
      "boot_ms": 41000,
      "features": []
    }
  ]
}

It never sends repository, workflow, job, branch or commit names, code, logs, secrets, cloud credentials, or anything from the job’s run.

When and where

One event per job started, sent in batches about once a minute.
A status lookup about once an hour, which returns your plan and your 30-day count for backmesh status.
Both go to https://api.backmesh.com, the one address to allow if you filter egress.
CI never waits on backmesh.com. Runners start the same way when it’s slow or down; events wait and go out once it answers.

The listener logs each batch it sends, in full, as one JSON line, so you can check the payload with anycloud logs backmesh.

How we use it

Your plan’s count. The only thing counts drive is the over-cap warning in backmesh status.
How many orgs and installs use backmesh, as two totals.
Capacity and product planning: jobs by cloud, region, VM type and pool, and how many installs use retrying on demand.
Reliability of spot and on-demand: the share of jobs on each.
Startup times: the median and 95th-percentile queue and boot times per cloud.

We look at these as totals across all installs, never per org. Nothing is sold or shared.

How it’s counted and kept

Your count is the number of distinct events from the last 30 days. For a paid plan, the counts of every org linked to the subscription add up.
Going over your plan’s cap only shows a warning in backmesh status. It never blocks a job.
An event dated in the future or more than 35 days back counts as received now.
Raw events are deleted after 90 days. A count per day, org and install is kept for billing questions.

Installs

An org admin signs in with GitHub once, during backmesh install. The sign-in asks only for read:org, so backmesh can check you’re an admin of the org; backmesh uses that GitHub token once and keeps none. It ties the install to your org: no one else can send events or read your plan for it.

The billing page lists each install reporting for a paid plan. If one isn’t yours, disown it there: its jobs stop counting and it can’t report again. If you think an install’s sign-in leaked, disown it there, then run backmesh upgrade on that install: it signs in with GitHub again as a new install, and the old sign-in stops working.