New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Node Response Time Review

by blotcms in blotcms/blot

Analyze production Node.js app container response times to find slow-rendering sites, cross-checking against nginx queuing delay to rule out false positives (a site only looks slow because the event…

AGPL-3.0Auto-check passedDevOps & Cloud

Install Node Response Time Review

skills CLI
$ npx skills add blotcms/blot --skill node-response-time-review -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install blotcms/blot node-response-time-review --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/blotcms/blot.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/node-response-time-review .claude/skills/node-response-time-review && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
node-response-time-review
GitHub stars
2k
Token cost
~1.9k tokens
SKILL.md length
821 words
Files
1
Skills in repo
7
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Analyze production Node.js app container response times to find slow-rendering sites, cross-checking against nginx queuing delay to rule out false positives (a site only looks slow because the event…

  • Works in 5 steps: Source of the technique → Get the data → Aggregate per domain → …
  • Asked to look for slow sites
  • SKILL.md covers 1. Source of the technique, 2. Get the data, 3. Aggregate per domain and 4. Classify each candidate, plus 1 more section
  • Calls ssh and gh

What it does

Node Response Time Review is an agent skill from blotcms/blot. Analyze production Node.js app container response times to find slow-rendering sites, cross-checking against nginx queuing delay to rule out false positives (a site only looks slow because the event loop was blocked by a different, pathological site). Use when asked to look for slow sites, investigate response times, or re-run the node response time analysis.

Its SKILL.md is about 1.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in DevOps & Cloud, covering Cloud networking and Async programming. It works with NGINX and Node.js. The repository describes itself as: Turns a folder into a website. The licence is AGPL-3.0.

When your agent uses it

  • Asked to look for slow sites
  • Investigate response times
  • Re-run the node response time analysis

Example prompts

  • “/node-response-time-review”

Requirements

  • Node.js
  • Docker

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Source of the technique
  2. Get the data
  3. Aggregate per domain
  4. Classify each candidate
  5. Report

What it can do on your machine

Read from SKILL.md and the folder at commit 9a0c75d. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • ssh
    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use ssh and gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Node Response Time Review loads about 1.9k tokens when it runs. Until then it costs about 97 tokens; SKILL.md has 821 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~97
When it runs · the whole SKILL.md, loaded when a task matches
~1.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from blotcms/blot at commit 9a0c75d, republished under its AGPL-3.0 licence (© blotcms). 821 words, ~1,871 tokens.

Download SKILL.mdSave it as .claude/skills/node-response-time-review/SKILL.md (or your agent's skills folder).
name
node-response-time-review
description
Analyze production Node.js app container response times to find slow-rendering sites, cross-checking against nginx queuing delay to rule out false positives (a site only looks slow because the event loop was blocked by a different, pathological site). Use when asked to look for slow sites, investigate response times, or re-run the node response time analysis.

Node.js response time review → problem-site identification

Reproduces the workflow from issue #1825: aggregate per-domain render times across the app containers, flag anything crossing the concern threshold, and distinguish genuinely slow sites from sites merely queued behind one.

Concern threshold: 150ms. Any single render over 150ms is worth a look; a site is worth flagging when a meaningful share of its requests exceed it, or its average render time is elevated (avg >150ms means most requests are slow, not just an occasional GC pause / cold cache).

This skill only identifies problem sites — it does not investigate root causes (why a given site is slow) unless separately asked to.

1. Source of the technique

The upstream alias in ~/.bashrc on the prod host (ssh blot) live-tails access.log for st=$upstream_response_time:

bash
alias upstream='tail -f /var/instance-ssd/logs/access.log | stdbuf -oL grep "st=[^-]" | stdbuf -oL awk "{print \$10, \$3, \$4, \$7}"'

That's a live view of nginx's upstream wait time — useful for watching traffic in real time, but it conflates two different things: the app actually being slow to render a site, vs. the app's single-threaded event loop being busy with a different concurrent request when this one arrived (queuing delay). At the ~15s nginx proxy timeout, both look identical from nginx's side alone. So this skill goes one step further and cross-checks against the app's own logged render time per request.

2. Get the data

SSH host is blot. Always confirm with the user before running anything against production; stick to read-only commands.

nginx access log (for cross-checking / a broader traffic sample, and to see 504s / true timeouts that never got a completion line in the app log):

bash
ssh blot "wc -l /var/instance-ssd/logs/access.log"

Log format (see config/openresty/conf/http.conf log_format access_log_format): space-separated, $7 = full URL, $10 = st= value (comma-separated if the request was retried across upstreams — sum the parts). st=- means no upstream was contacted (pure cache hit) — skip those lines. Exclude blot.im's own long-lived endpoints, which are long-polling by design, not bugs:

^https://blot\.im/sites/[^/]+/status   (publish-status long poll)
^https://webhooks\.blot\.im/           (webhook delivery)
/draft/stream/                          (live preview SSE)

App container logs (the authoritative source for "did the app itself take a long time to render this"). Check container uptime first — a recent deploy/restart limits how far back --since can usefully go:

bash
ssh blot "docker ps --format '{{.Names}}\t{{.Status}}'"
for c in blue green yellow; do
  ssh blot "docker logs --since 6h blot-container-$c 2>&1"
done > /tmp/app_logs_combined.txt

Completed-request lines look like: [12/Sep/2026:09:29:23 +0000] [yellow] <request-id> 200 0.013 https://www.example.com/path — fields: $3=[color], $4=request id, $5=status, $6=render time (seconds), $7=url. A request that hangs past nginx's timeout never gets this line — instead you'll see <request-id> Connection closed by client <url> once nginx gives up. That's itself a strong signal: search for it directly (grep "Connection closed by client") to catch sites whose worst requests are too slow to even produce a normal timing line.

3. Aggregate per domain

bash
awk '
{
  if ($3 ~ /^\[(blue|green|yellow)\]$/ && $5 ~ /^[0-9]+$/ && $6 ~ /^[0-9]+\.[0-9]+$/ && $7 ~ /^https?:\/\//) {
    t = $6 + 0; url = $7;
    n = split(url, u, "/"); domain = u[3];
    if (domain == "") next;
    count[domain]++; sum[domain] += t;
    if (t > max[domain]) max[domain] = t;
    if (t > 0.15) over150[domain]++;
    if (t > 1) over1s[domain]++;
  }
}
END {
  for (d in count)
    printf "%s\tcount=%d\tavg=%.4f\tmax=%.3f\tover150ms=%d\tover1s=%d\tpct150=%.1f\n",
      d, count[d], sum[d]/count[d], max[d], over150[d]+0, over1s[d]+0, (over150[d]+0)*100/count[d]
}' /tmp/app_logs_combined.txt > /tmp/app_domain_stats.txt

Rank by average render time and by pct150 (share of requests over the 150ms bar), filtering out low-traffic domains (count < 20 or so — too noisy to draw conclusions from a handful of requests):

bash
awk -F'\t' '{
  for(i=1;i<=NF;i++){split($i,kv,"="); v[kv[1]]=kv[2]}
  if (v["count"]+0 >= 20) print v["avg"], v["count"], v["pct150"]+0, v["max"], $1
}' /tmp/app_domain_stats.txt | sort -rn | head -40
Show full SKILL.md (374 more words)Show less

4. Classify each candidate

For every domain that crosses the threshold, characterize how it's slow — this determines severity and whether it's a false positive:

  • High avg AND high pct150 AND high max (e.g. nashp.com: avg 3.8s, 75%

    150ms, max 17s) → genuinely, severely slow. Real bug, high priority.

  • High pct150 but low max, avg well above 150ms but well below 1s (e.g. chuckpearson.blog: avg 0.78s, 87% >150ms, max only 1.7s) → consistently moderately slow on nearly every request, not occasional spikes. Also real, but a different shape of problem (steady overhead vs. pathological worst case) — worth noting as such.
  • Moderate pct150, avg comfortably under 150ms (e.g. karaman.is: avg 0.44s pulled up by a handful of outliers, but most requests fast) → borderline; note it but don't treat as confirmed without a second look.
  • High nginx-level st= numbers but the SAME domain's app-log render times are almost all fast (e.g. www.markwadley.com: nginx avg 3s / 25%

    3s, but app-log avg 0.24s / 12% >150ms with no correlation) → false positive. The slowness measured at nginx is queuing delay from a different concurrent request blocking the event loop, not this site's own cost. Don't flag it as the site's problem.

  • No completed app-log lines at all, but nginx shows requests and/or Connection closed by client for the domain (e.g. anchor.blot.im) → the app never finished rendering within the proxy timeout at all. This is a severe finding even with a tiny sample size — a single hang beyond 15s matters more than a moderate average.

Always sanity-check a top candidate against TODO in the repo root — some slow sites are already known/tracked (e.g. "Fix performance issues with nashp", "Fix issue with warwickmostyn").

5. Report

Don't file a new issue every run — this is a recurring check. Update the existing tracking issue (currently #1825) with the current window's numbers via gh issue edit (replace body) or gh issue comment (append), rather than creating a duplicate. Structure the update as: threshold/method recap, confirmed slow sites (with the avg/pct150/max numbers and the app-vs-nginx evidence), false positives ruled out, and anything low-confidence that needs another pass. Keep root-cause speculation out unless asked — this skill is about identification only.

Clean up scratch files on both ends when done: ssh blot "rm -f /tmp/app_logs_combined.txt" and remove any local /tmp/app_domain_stats.txt equivalents.

© blotcms, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/node-response-time-review of blotcms/blot.

Open the folder on GitHubat commit 9a0c75d

Compare with similar skills

Node Response Time Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Node Response Time Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Node Response Time Review this skillblotcms/blot2k—~1.9kAutomated safety check: PassAGPL-3.0
Baota Panel Experttheneoai/awesome-skills183—~3kAutomated safety check: PassMIT
Nginx To Higress Migrationhigress-group/higress9.5k—~3.9kAutomated safety check: PassApache-2.0
NGINX Ingress Controller Feature Checklistsnginx/kubernetes-ingress5.1k—~1.4kAutomated safety check: PassApache-2.0
NGINX Ingress Policy CRD Guidenginx/kubernetes-ingress5.1k—~2kAutomated safety check: PassApache-2.0
Wp Static Clonejdevalk/skills104—~2.6kAutomated safety check: PassMIT

Similar skills

  • Baota Panel Expert

    theneoai/awesome-skills

    宝塔面板专家。Use when: 管理Linux服务器、配置宝塔面板、部署网站、配置SSL、迁移数据、优化性能. An agent skill from theneoai/awesome-skills.

    183 GitHub stars~3k tokensUpdated 4 mo ago
    DevOps & CloudAuto-check passed

  • Nginx To Higress Migration

    higress-group/higress

    Migrate from ingress-nginx to Higress in Kubernetes environments.

    9.5k GitHub stars~3.9k tokensUpdated 2 days ago
    DevOps & CloudAuto-check passed

  • NGINX Ingress Controller Feature Checklists

    nginx/kubernetes-ingress

    Gives step-by-step checklists for adding Ingress annotations, VirtualServer fields and Helm values to the NGINX Kubernetes Ingress Controller, with common gotchas.

    5.1k GitHub stars~1.4k tokensUpdated today
    DevOps & CloudAuto-check passed

  • NGINX Ingress Policy CRD Guide

    nginx/kubernetes-ingress

    Step-by-step checklist for adding a new Policy CRD type to the NGINX Ingress Controller, from the Go types and validation to config generation and templates.

    5.1k GitHub stars~2k tokensUpdated today
    DevOps & CloudAuto-check passed

  • Wp Static Clone

    jdevalk/skills

    Clones a live WordPress (or other CMS-driven) site into a static HTML site deployable on any static host (Cloudflare Pages, Netlify, Vercel, S3+CloudFront, plain Apache/nginx).

    104 GitHub stars~2.6k tokensUpdated 3 mo ago
    DevOps & CloudAuto-check passed

  • Examples Checker

    eclipse-ankaios/ankaios

    Check Ankaios examples by building and running each example in the devcontainer and validating they work correctly.

    125 GitHub stars~2k tokensUpdated 2 days ago
    DevOps & CloudAuto-check passed

More from blotcms/blot

  • Folder Links Review

    blotcms/blot

    Review what Blot's request-time folder-link rewrite (app/blog/render/replaceFolderLinks) still does in production, from the [folder-links] and [folder-asset-origin] log lines, to decide what has to…

    2k GitHub stars~2.2k tokensUpdated today
    Auto-check passed

  • Investigate Dropbox Sync Issue

    blotcms/blot

    Investigate a "Dropbox sync issue" alert email from Blot's hourly Dropbox sync validation ("detected previously unsynced changes from Dropbox for the following sites").

    2k GitHub stars~3.8k tokensUpdated today
    Auto-check passed

  • Investigate Production Container Restarts

    blotcms/blot

    Work out why the blot-container-{blue,green,yellow} Docker containers from the most recent production deployment have restarted — distinguishing a normal deploy-triggered restart from a crash (V8…

    2k GitHub stars~4.7k tokensUpdated today
    Auto-check passed

  • Investigate Slow Upstream Responses

    blotcms/blot

    Scan the production openresty access log (/var/instance-ssd/logs/access.log) for requests with slow upstream response times (st=, the time the node containers took to answer), triage and rank them…

    2k GitHub stars~3.6k tokensUpdated today
    Auto-check passed

  • Triage Sync Fix Repair

    blotcms/blot

    Triage a "sync/fix repaired <handle" admin email ("Fix() found and repaired issues for blog… (handle, client: …)"), sent whenever sync/fix (Fix()) changes anything for a blog.

    2k GitHub stars~3.5k tokensUpdated today
    Auto-check passed

  • Preview

    blotcms/blot

    Run this git worktree's code in its own local server at https://slot-local.blot (slots a-e) so the operator can see and click through it while the main stack keeps running.

    2k GitHub stars~649 tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Node Response Time Review

What does Node Response Time Review do?

Analyze production Node.js app container response times to find slow-rendering sites, cross-checking against nginx queuing delay to rule out false positives (a site only looks slow because the event…. Node Response Time Review is an agent skill from blotcms/blot.js app container response times to find slow-rendering sites, cross-checking against nginx queuing delay to rule out false positives (a site only looks slow because the event loop was blocked by a different, pathological site).

When should I use Node Response Time Review?

Node Response Time Review fits situations like: asked to look for slow sites; investigate response times; re-run the node response time analysis.

How do I install Node Response Time Review in Claude Code?

Run `npx skills add blotcms/blot --skill node-response-time-review -a claude-code`. Or copy the skill folder (.claude/skills/node-response-time-review in blotcms/blot) into .claude/skills/node-response-time-review in your project. Claude Code loads it when a task matches its description.

How do I install Node Response Time Review in Codex?

Run `npx skills add blotcms/blot --skill node-response-time-review -a codex`. Or copy the skill folder (.claude/skills/node-response-time-review in blotcms/blot) into .agents/skills/node-response-time-review in your project. Codex loads it when a task matches its description.

Can I use Node Response Time Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add blotcms/blot --skill node-response-time-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/node-response-time-review, .gemini/skills/node-response-time-review, .github/skills/node-response-time-review and .opencode/skills/node-response-time-review in your project.

What does Node Response Time Review need to run?

Going by SKILL.md and its folder, Node Response Time Review needs the command-line tools its instructions call (ssh and gh). Our summary lists: Node.js; Docker.

Does Node Response Time Review access the network?

SKILL.md contains no URLs. Its commands use ssh and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Node Response Time Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Node Response Time Review use?

Node Response Time Review is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Node Response Time Review use?

About 1.9k tokens (SKILL.md is roughly 7.5k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Node Response Time Review?

Skills that share tags, products or a category with Node Response Time Review: Baota Panel Expert (theneoai/awesome-skills, 183 stars), Nginx To Higress Migration (higress-group/higress, 9.5k stars), NGINX Ingress Controller Feature Checklists (nginx/kubernetes-ingress, 5.1k stars) and NGINX Ingress Policy CRD Guide (nginx/kubernetes-ingress, 5.1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Node Response Time Review?

blotcms (a GitHub organization) maintains it in blotcms/blot, which has 1,983 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on October 7, 2026.

Source: blotcms/blot on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.