22 days ago
I publish a few templates and I'm trying to understand how the projects count on a template is calculated, because for one of mine it looks lower than the number of deploys I believe have happened.
The template in question is public here, in case anyone wants to look at its config: https://railway.com/deploy/vector-knowledge-base-api
The specifics:
- It's published and healthy (100%), and it does accrue some kickback, so it's being deployed and attributed at least at the billing level.
- But it shows projects: 1 / activeProjects: 1 / recentProjects: 1, even though I'm fairly sure it's been deployed several times (including my own test deploys from a separate account).
- By contrast, my other published templates show counts in the double digits, which matches what I'd expect.
My questions for anyone who's run into this:
- What does projects actually count? Unique deploying accounts? Only currently-linked projects? Does it exclude deploys from the author's own or related accounts, and does it go down when a deployed project is deleted or ejected?
- How do projects, activeProjects, and recentProjects differ (time windows, counting rules)?
- Has anyone noticed a difference in counting for a template whose service builds from a GitHub repo vs. one built entirely from prebuilt Docker images? The under-counted template is the only one of mine with a repo-backed service, so I want to rule that in or out.
- Is a low projects number expected behavior in some cases (i.e. the counter is a filtered/deduped view), or would it usually indicate deploys not registering?
If anyone has a moment to glance at the template and spot something misconfigured that could affect attribution, that'd be hugely appreciated. Mainly trying to understand whether the counter reflects all attributed deploys or just a filtered subset, and whether others have seen the same pattern.
2 Replies
22 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 22 days ago
2 days ago
The public projects / activeProjects / recentProjects fields are not currently documented as the authoritative deployment counter.
Railway's current Template Metrics documentation defines Deployments in the template's private Metrics tab as “total number of times your template has been deployed,” while saying the extended metrics section is still under construction:
https://docs.railway.com/templates/metrics
So the first useful comparison is:
- Workspace → Templates → Edit this template → Metrics.
- Compare its Deployments value with the public
projectsvalue. - Compare Earnings/kickback events separately.
If Deployments and earnings are higher than the public projects field, attribution is working and the public field is a filtered/cached presentation metric. In that case I would not change the template config to “fix” it.
The GitHub source is unlikely to explain kickback attribution. Railway documents GitHub-backed vs image-backed templates differently only for update notifications: GitHub templates can notify consumers about upstream updates; Docker-image templates currently cannot. It does not document a different deployment-attribution path:
https://docs.railway.com/templates/updates
If the private Metrics Deployments count is also 1, then this needs Railway to reconcile the specific template against known deployed project IDs. Include the template code plus 2–3 project IDs/timestamps in a private support thread (not publicly) so they can distinguish:
- a deployment that originated from this exact published template revision,
- a manual clone/recreation that looks identical but is not template-attributed,
- deleted/test/self-owned projects that may be excluded from a public popularity count,
- and any delayed metrics aggregation.
What can be said confidently from the public docs is: Deployments in Metrics is the total-deploy metric; earnings is the payout-attribution signal; the three public project fields have no published counting/window definitions today. Because your template already accrues kickback, the repo-backed service itself is not breaking attribution.
ayalaa12
The public `projects / activeProjects / recentProjects` fields are not currently documented as the authoritative deployment counter. Railway's current Template Metrics documentation defines **Deployments** in the template's private Metrics tab as “total number of times your template has been deployed,” while saying the extended metrics section is still under construction: https://docs.railway.com/templates/metrics So the first useful comparison is: 1. Workspace → Templates → Edit this template → Metrics. 2. Compare its **Deployments** value with the public `projects` value. 3. Compare Earnings/kickback events separately. If **Deployments** and earnings are higher than the public `projects` field, attribution is working and the public field is a filtered/cached presentation metric. In that case I would not change the template config to “fix” it. The GitHub source is unlikely to explain kickback attribution. Railway documents GitHub-backed vs image-backed templates differently only for update notifications: GitHub templates can notify consumers about upstream updates; Docker-image templates currently cannot. It does not document a different deployment-attribution path: https://docs.railway.com/templates/updates If the private Metrics **Deployments** count is also 1, then this needs Railway to reconcile the specific template against known deployed project IDs. Include the template code plus 2–3 project IDs/timestamps in a private support thread (not publicly) so they can distinguish: - a deployment that originated from this exact published template revision, - a manual clone/recreation that looks identical but is not template-attributed, - deleted/test/self-owned projects that may be excluded from a public popularity count, - and any delayed metrics aggregation. What can be said confidently from the public docs is: **Deployments** in Metrics is the total-deploy metric; earnings is the payout-attribution signal; the three public project fields have no published counting/window definitions today. Because your template already accrues kickback, the repo-backed service itself is not breaking attribution.
a day ago
thanks! for some reason I didn't see the metric section on edit template, that definetly clarifies it