hostinger/hostinger-cursor-plugin · Archived

query-deployment-logs

Pull and summarize the logs Hostinger's API exposes — Node.js build logs, JS deployment logs, and cron job output — for a domain. Use to investigate a failed or slow build, or a cron job that isn't doing what the user expects.

First seen Aug 9, 2026

Installation

$ npx skills add hostinger/hostinger-cursor-plugin --skill query-deployment-logs

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from hostinger/hostinger-cursor-plugin.

npx skills add hostinger/hostinger-cursor-plugin

Browse all from hostinger/hostinger-cursor-plugin

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 2
License LICENSE
Default branch main
Open issues 0
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,001 B
  • docs SUMMARY.md 259 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

Query Hostinger logs

What is actually available

Hostinger's API exposes three kinds of log output:

Log Tool Needs
JS deployment logs hosting_showJsDeploymentLogs domain, buildUuid, optional fromLine
Node.js build logs hosting_getNodeJSBuildLogsV1 username, domain, uuid, optional from_line
Cron job output hosting_getCronJobOutputV1 cron job identifiers from hosting_listAccountCronJobsV1

Raw HTTP access logs and PHP error logs are not exposed by the API. If the user asks for 4xx/5xx breakdowns, traffic spikes, per-request timings, or PHP fatals, tell them directly that these live in hPanel and cannot be fetched here. Do not substitute a plausible-sounding tool name, and do not present build logs as if they were access logs.

Inputs to gather first

  1. Domain.
  2. Which log the user actually needs — a build/deployment, or a cron job.
  3. For builds: the build uuid. Get it from hostinglistJsDeployments or hostinglistNodeJSBuildsV1, filtering states when the user only cares about failures.
  4. For hostinggetNodeJSBuildLogsV1: the username, from hostinglistWebsitesV1.

Steps

  1. Resolve the build or cron job identifier first — every log tool requires one.
  2. Fetch the log, starting at line 0.
  3. To follow a running build, poll while the state is running, passing the previously returned line count as fromLine / from_line so each call returns only new output.
  4. Strip ANSI escape sequences before quoting — build output is colorized.
  5. Summarize rather than dumping. Report:

- The final state and, for a failure, the first error and the last 20 lines verbatim. - Which step failed (install, build, start). - Total duration, if the timestamps allow it.

  1. Offer drill-down: "Want the full log?", "Want me to compare this against the last successful build?".

Handing off

  • A failed build with an identified error signature → diagnose-build-failure.
  • A cron job producing no output → check the schedule and command with hosting_listAccountCronJobsV1 before assuming the script is broken.

Privacy

  • Build logs can echo environment values and tokens. Redact anything that looks like a credential before quoting, and never paste a full environment dump into chat.

Do not

  • Do not dump thousands of log lines into the conversation — page through and summarize.
  • Do not infer a cause from a single line; corroborate with the surrounding context.
  • Do not claim access-log or error-log capability the API doesn't have.