Publishing a Report

Publishing a Report

Binding a project to a GitHub repository (see Activating the Plan) grants the Open Source plan's quota. It does not, by itself, publish anything — a bound project can stay completely private. Publishing is a second, deliberate step, and each project in an Open Source workspace chooses independently.

Turning it on

Steps

1. Go to Project Settings → General for the project you want to publish.
2. Find the Public report toggle and turn it on.
3. Your report is now live at https://reports.qualflare.com/p/<project-slug>/launches — anyone with the link can view launch results without a Qualflare account.
4. Turn the toggle off at any time to unpublish. The report becomes inaccessible immediately; no data is deleted.

What viewers see

A published report shows your project's name, description, and overall pass rate, followed by a table of launches — run number, timestamp, git branch, commit, duration, and pass/fail status. Clicking a launch opens a per-test breakdown. No sign-in is required, and it's entirely read-only.

Every public report page also carries a link back to Qualflare (in the header and footer) framed as "free for open source" — the same growth loop your own badge or banner participates in.

Embeddable badge

A compact, shields.io-style status image for a badge row at the top of your README:

[![Qualflare](https://api.qualflare.com/p/<project-slug>/badge.svg)](https://reports.qualflare.com/p/<project-slug>/launches)

Embeddable banner

A wider card — project name (or, if your repository is linked, its owner/repo name instead of whatever the project is called inside Qualflare), pass rate, run count, flaky-case count, last-run time, and a GitHub-activity-style grid of recent runs:

[![Qualflare](https://api.qualflare.com/p/<project-slug>/banner.svg)](https://reports.qualflare.com/p/<project-slug>/launches)

Badge or banner? The badge is a compact chip that reads naturally alongside other status badges (build, license, version). The banner is a richer, standalone summary — better suited to its own line near the top of a README, where there's room for it.

Both images update automatically as new launches come in — there's nothing to regenerate or re-embed after your first run.

Quota and plan limits

The Open Source plan isn't literally unlimited. Every volume limit is capped at the same ceiling as the paid Scale plan — generous for a normal open-source project, but a real, finite number:

AI features are mostly off on this plan — failure clustering, launch analysis, and test-suite optimization are all disabled. The one exception is the Quo agent, at Starter-plan parity: 10 messages a day, 100 a month.

The suspend-and-restore lifecycle

A repository is re-checked against the eligibility rules on an ongoing basis, not just once at link time. If it stops qualifying — goes private, gets archived, or the license changes — here's what happens, and when:

1. A transient check failure never counts against you. If GitHub is temporarily unreachable or returns an error, that's tracked separately and never starts the countdown below — a GitHub outage doesn't suspend every Open Source project on the platform at once.
2. A definitive failure starts a 7-day grace period. Once a repository is confirmed ineligible (not just a flaky check), you have 7 days to fix it before anything changes.
3. After 7 days with no fix, the project is suspended and unpublished automatically. The public report goes offline; the project itself isn't deleted.
4. If the repository becomes eligible again — at any point, even after suspension — it's restored automatically. There's no support ticket to file and nothing to manually re-request; fixing the underlying issue (e.g. making the repo public again) is enough.

Related

• Activating the Plan — eligibility rules and the linking flow
• Setting Up CI — get real launches showing up on the report
• FAQ — what happens to a report that goes dark, and other common questions