You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the unverified deploy state and the live activity grid (#84)
The Status tab gained a headline for a live site whose pages carry no build
marker, and a grid of check-ins by the hour under the status card. Both are
described here, along with the rule the Protection stage uses and the way the
connector now labels CI builds of a production branch.
Copy file name to clipboardExpand all lines: src/content/docs/Patchstack App/Pulse/deploy-history.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -50,7 +50,7 @@ This matters if you scan from more than one place. Production and sandbox builds
50
50
51
51
With no environment selected, the view follows the site's most recent build, so an app that only ever scans from a sandbox still gets a real timeline.
52
52
53
-
You can set the environment a scan reports as with `PATCHSTACK_ENVIRONMENT`, or `environment` in `.patchstackrc.json`. When nothing sets it, the scan reports where it ran: a build on your hosting platform or in CI reports `production`, and a scan on a developer's machine reports `local`. Local builds are kept as their own lineage too, so the packages you tried on a laptop never show up as production churn.
53
+
You can set the environment a scan reports as with `PATCHSTACK_ENVIRONMENT`, or `environment` in `.patchstackrc.json`. When nothing sets it, the scan reports where it ran. A build your hosting platform makes for its production deployment reports `production`, and so does a CI build of your production branch (`main`, `master`, `production`, `prod`, `release` or `live` on GitHub Actions, GitLab CI, Cloudflare Pages, AWS Amplify and similar). A preview, a pull-request build or a build of any other branch reports `sandbox`. A scan on a developer's machine, or in a CI runner Patchstack cannot place, reports `local`. Local builds are kept as their own lineage too, so the packages you tried on a laptop never show up as production churn.
Copy file name to clipboardExpand all lines: src/content/docs/Patchstack App/Pulse/pulse-overview.md
+9-1Lines changed: 9 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -50,9 +50,16 @@ The headline is one of:
50
50
-**Needs deploying** — a newer build has been scanned than the one the live site is serving.
51
51
-**Deployed** — the live site is running a build Patchstack scanned. The date is when the build was seen to change on the live site; where nothing has changed under observation, it is the build time, labelled as such.
52
52
-**Deployed without Patchstack** — the live site is running a build that was never scanned. Run the build again with `@patchstack/connect` installed.
53
+
-**Live, build unverified** — the widget is checking in from the site's address, but the page carries no build marker, so nothing says which build is running. This is what a build made on your own machine looks like once it is uploaded by hand: the connector only stamps the marker on a build it can tell is a deployment. Build for publishing with `PATCHSTACK_ENVIRONMENT=production`, or run `npx @patchstack/connect mark-build --production` before uploading, and the next deploy reads as **Deployed**.
53
54
-**Deploy state unknown** — production builds exist, but nothing current says which one is live.
54
55
55
-
Next to the headline, **Reporting from** names the environment Patchstack last heard from — *local machine*, *sandbox*, or *production*. **Built with** names the builder when one was recognised, and **Hosted on** names the platform serving the site (Netlify, Vercel, Cloudflare, DigitalOcean, AWS, GitHub Pages and others), as read from the build's own environment and confirmed from the live page's response headers. The four stages below them (**Configured**, **Deployed**, **Monitoring**, **Protection**) are each graded from what was actually observed, with its timestamp. A stage is not ticked because a later one is: an app can be live without a production scan, and the card says so.
56
+
Next to the headline, **Reporting from** names the environment Patchstack last heard from — *local machine*, *sandbox*, or *production*. **Built with** names the builder when one was recognised, and **Hosted on** names the platform serving the site (Netlify, Vercel, Cloudflare, DigitalOcean, AWS, GitHub Pages and others), as read from the build's own environment and confirmed from the live page's response headers. The four stages below them (**Configured**, **Deployed**, **Monitoring**, **Protection**) are each graded from what was actually observed, with its timestamp. A stage is not ticked because a later one is: an app can be live without a production scan, and the card says so. The **Protection** stage is ticked when protection is on for the site, whether through the per-site add-on or a plan that protects every site — the same rule the site header and the widget use.
57
+
58
+
### Live site activity
59
+
60
+
Under the status card, **Live site activity** shows how often the site has been heard from over the last seven days, hour by hour, in your local time. Each cell is one hour; the deeper the green, the more check-ins in that hour. A check-in is a visitor's browser running the widget on the live site, or Patchstack's own scheduled read of the page. An outlined cell marks an hour in which a build reported its packages. Hover a cell for the exact counts.
61
+
62
+
The headline above the grid says when the site was last heard from and by which witness, and reads **Checking in** while the last check-in is under an hour old. The grid is the difference between a site with visitors and one somebody opened once: the status card can say the site was seen five minutes ago, but only the grid can say whether that was the first time this week or the four-hundredth. Check-ins are kept for 30 days.
56
63
57
64
Every status that is not the finished one names the next step. For a locally configured app that is: add `PATCHSTACK_API_KEY` to the hosting platform's environment, commit the generated changes, and deploy. Expand **What this is based on** to see every signal behind the verdict — a scan on a developer machine, a production build, the widget checking in from the live site, Patchstack's own fetch of the page — with where each came from and when.
58
65
@@ -82,6 +89,7 @@ The connector's `mark-build` step stamps each build's fingerprint into the HTML
82
89
|**Last build \<when\>**| The same, except nobody has seen this app change build since Patchstack started watching. The time shown is when the build ran, not when it went live. |
83
90
|**Needs deploying**| A newer build was scanned, but the live site is still serving an older one. Deploy to put it live. |
84
91
|**Deployed without Patchstack**| The live site is running a build Patchstack never scanned — the build ran without the connector. Run the build again with `@patchstack/connect` so its packages get checked. |
92
+
|**Live, build unverified**| The widget is checking in from the site's address, but the page carries no build marker, so nothing can say which build is live. Typically a build made on a developer's machine and uploaded by hand. Build with `PATCHSTACK_ENVIRONMENT=production`, or run `mark-build --production` before uploading. |
85
93
|**Sandbox only**| Builds have been reported, but only from a sandbox. Nothing has gone to production yet. |
86
94
|**Build environment**| This site is a build environment rather than a live one. Deploys are tracked on the production site it belongs to. |
87
95
|**Deploy state unknown**| Nothing current names the live build — usually a site with no traffic that Patchstack also cannot fetch. |
0 commit comments