Troubleshooting

Each entry is named after what you see. Where the cause is covered in more detail elsewhere, the entry links to that page.

Starting a run or a schedule¶

Nothing happens when I press Start pentest¶

Cause. The console does not display an error from Start pentest. When the ownership re-check refuses the launch, the engagement becomes blocked, but the page keeps showing pending and the button until you reload it.

What to do. Reload the page. If the status reads blocked, submit the same engagement again with POST /api/engagements/{id}/submit; the console has no button for a blocked engagement. While the launch is still refused, the 409 response names each identifier and the reason. Publish the missing record or renew the attestation, then submit again. See Ownership verification and Lifecycle.

Create engagement does nothing¶

Cause. The request to create the engagement failed. The wizard does not show the error: it stays on the Review step and the button becomes available again.

What to do. Reload the console. If it takes you to the sign-in page, your session has expired; sign in and fill in the wizard again (Organizations). If the create fails again while you are signed in, contact Pentr support.

[object Object] in the schedule wizard¶

Cause. The server rejected the cadence or the schedule, and the wizard cannot display the text of that rejection. It appears in the Next 3 runs panel on the Cadence step, or on the Review step after Create schedule.

What to do. Check the expression against the one-hour floor, and check that the timezone is an IANA zone name (Timezones and DST). Sending the same cadence to POST /api/schedules/preview returns the server's message.

A schedule's row shows last occurrence skipped: …¶

Cause. The most recent occurrence did not launch. The text after the colon is one of four reasons:

Reason	Cause	What to do
creator user no longer exists	The user who created the schedule no longer exists	Contact Pentr support
plan cap: …	The organization already had as many engagements queued or running as the tier allows	Nothing; the cap is checked again at the next occurrence
launch refused, ownership not proven for …	The ownership re-check refused an identifier, and a blocked engagement was left behind	Publish the missing proof before the next occurrence
error: …	Something else failed while the occurrence fired	Contact Pentr support

A skipped occurrence is not retried. See Caps and skips and Plans and limits.

While a run is in flight¶

An engagement stays at queued¶

Cause. The scheduler runs one engagement at a time, in the order they were queued, and no timer limits how long a run takes. A queued engagement waits for every run ahead of it. Until its container starts, the live output reads waiting for events…. See Running an engagement.

What to do. Wait. A queued engagement cannot be cancelled. If it stays at queued for much longer than you expect, contact Pentr support.

The page reads completed, but no findings appear and Generate report does nothing¶

When the run ends, the engagement's page changes to completed, but the Findings list stays empty and pressing Generate report brings the button back without a report. The Engagements page lists the same engagement as running. Reloading the engagement's page within 24 hours of the run's end shows the same thing again. After that, it reads running, and the live output reads waiting for events….

Cause. The run's result was not saved when the run ended, so the engagement's stored status is still running and it has no findings (Lifecycle). The engagement's page shows completed because it replays the run's progress trace, which ends with the completion line and is kept for 24 hours. A report is generated only for an engagement stored as completed. While the engagement reads running it counts towards the plan cap, so scheduled occurrences can be skipped for the cap.

What to do. Contact Pentr support. Nothing in the console or the API moves the engagement to another status.

Lines in the live output appear twice¶

Cause. The connection to the progress stream dropped and reconnected. A reconnection replays the trace from its first event, and the console adds the replayed events after the ones it already shows.

What to do. Reload the page. The trace is then replayed once. See Running an engagement.

The live output stops updating during a long run¶

The output stops without a final line marked ✓ or ✕. If the page instead reads completed and no findings appear, see The page reads completed, but no findings appear and Generate report does nothing above.

Cause. A run's progress trace holds its most recent 5,000 events. Once a run has produced that many, the page receives no new events. The run itself continues. See Running an engagement.

What to do. Reload the page to see the engagement's current status. The findings and the report appear once the engagement is stored as completed. If the status does not change for much longer than you expect, contact Pentr support.

The live output disappears when the run ends¶

Cause. The console shows the live output only while the engagement is queued or running.

What to do. Read the trace from GET /api/engagements/{id}/progress. It is kept for 24 hours. See When a run fails.

After a run¶

A run completes with no findings and five error lines in its trace¶

Cause. Five consecutive failing steps end a run, which is then recorded as completed. The error lines name what failed. When they name an overlap between the in-scope and out-of-scope lists, the run stopped in its first phase because of that overlap. See When a run fails.

What to do. If the lines name a scope overlap, remove it and create a new engagement; a completed engagement cannot be submitted again. See Scope. If they name anything else, contact Pentr support.

The Report panel has no report¶

Cause. A report exists only for a completed engagement. On any other status the panel reads Available once the engagement completes., and a request to generate one is refused with a 400. A failed engagement never gets a report. On a completed engagement, a Generate report button means the first attempt to generate it failed.

What to do. On a completed engagement, press Generate report. If the button comes back without a report and the Engagements page lists the engagement as running, see The page reads completed, but no findings appear and Generate report does nothing above. On a failed engagement, create a new engagement. See Findings & reports and When a run fails.

Create link fails with "is not sealed; there is nothing to share"¶

Cause. A share link can be created only for a sealed run, and this run was not sealed. The message was sealed before signing was introduced means the run's seal has no signature, which has the same effect.

What to do. An unsealed run stays unsealed: there is no re-seal. Its report and its SARIF and CSV exports still work. For evidence you can share, run the test again as a new engagement. If every completed run is unsealed, contact Pentr support. See Sealing.

A recipient cannot open a share link¶

Cause and what to do. The share page names the problem:

The recipient sees	Cause	What to do
"This link is incomplete — the part after the # character is missing. Ask the sender to resend the whole URL."	The part of the URL after # did not arrive	Send the full URL again, in a form that keeps everything after # intact
"This share link was not found. Check that the whole link was copied, including everything after the # character." (404)	No link carries the token, usually because the URL was truncated	Send the full URL again, including the part after #
"This share link has expired or been revoked. Ask whoever sent it for a new one." (410)	The link is past its expiry or was revoked	Create a new link
"Too many requests from this address. Try again in a minute." (429)	A rate limit; the response carries a Retry-After header	Wait and retry
"The evidence store is not reachable right now. Try again later." (any status other than 404, 410 or 429)	The server returned an error status it has no specific message for, for example its own 500 when it cannot read the run's evidence	Contact Pentr support
"Could not load this evidence locker."	Loading the share page failed outright: a network failure, or a successful (2xx) response whose body was not valid JSON	Check the connection and reload; if it persists, contact Pentr support
"Download failed."	Downloading the locker failed outright: a network failure, or a failed read of the response body	Retry the download; if it persists, contact Pentr support

See Share links.

Locker export returns 409 or 500¶

Cause. A 409 means the run is not sealed, or was sealed without a signature, so there is nothing to export. A 500 means the server cannot read the run's evidence or the signing key the seal names. See Exporting a locker.

What to do. For a 409, see the share-link entry above: the same run cannot be sealed later. For a 500, contact Pentr support.

pentr-verify exits with 1 or 2¶

Cause. Exit 1 means the file is a locker and it did not verify; the output names what failed. Exit 2 means the tool could not begin: the path does not exist, the file is not a locker it can read, or the key passed to --key could not be read.

What to do. For exit 2, check the path and the key file first. For exit 1, read the failure codes. See Verifying a locker.

Signing in¶

The password-reset email does not arrive¶

What to do. Contact Pentr support.