Quick answer
First confirm that the entry really has no active assigned step. If execution stopped between transitions, correlate the last successful workflow event with private PHP and application logs. Reproduce the failing action once in an isolated staging workflow. Do not repeatedly restart the live entry, because earlier messages or external requests may already have succeeded.
Distinguish waiting from interrupted execution
A pending label alone does not identify the fault. An entry may be waiting for a reviewer, a scheduled action, or another legitimate condition. Check the entry detail and timeline to identify the current step and intended assignee. Record what the interface actually shows instead of translating every pending state into a PHP error.
If no active task is visible, note the last completed step and the action that should have followed it. Ask whether the symptom began after a plugin update, custom-code change, or configuration edit. Record those changes as leads, not proven causes. The timeline should remain the starting point for correlation.
Create a minimal incident record
Keep the entry ID, form ID, workflow step ID, timestamp with timezone, installed versions, and expected next action together. Add the request path or action name where available, but omit submitted client content unless it is essential to an authorized investigation. A small reproducible record is more useful than a large unfiltered export.
Inventory any side effects before the stall: notifications, webhook calls, account changes, and CRM writes. Note whether each is confirmed, failed, or unknown. This list matters during recovery because the absence of the next local step does not prove that an external operation failed.
Collect logs without exposing them publicly
Gravity Flow documents custom PHP failures and plugin conflicts among possible causes of this symptom. Use private server logs and the product's supported logging controls to capture the relevant execution. Have the hosting or development owner set a narrow collection window and protect the resulting files from public access.
Avoid turning on visible PHP error display for customers. Debug files can contain paths, identifiers, tokens, and submitted values. Review and redact material before sharing it. Remove temporary logging after the test and follow the organization's retention rules rather than leaving an unrestricted debug log in the web root.
Reproduce one boundary on staging
Use a copy with fictional data and sandbox or disabled external destinations. Reproduce the action immediately before the last known good transition. Capture the first meaningful exception and its owning component. A later warning may be a consequence, so keep the event sequence rather than quoting only the final line.
Test the suspected custom hook or plugin combination under controlled conditions. Do not deactivate the whole production plugin stack to see whether the symptom changes. When a clean staging configuration still fails, retain the smallest fixture that demonstrates it and use it for a vendor support report.
Separate technical repair from entry recovery
A code fix and a stalled-entry recovery are two different tasks. First verify that a new fictional entry reaches the next expected step without the error. Then decide how each existing entry should resume, using the side-effect inventory to prevent duplicate messages or integrations.
If the preceding webhook outcome is unknown, reconcile it with the destination using a safe identifier before replaying it. Do not assume that a timeout means nothing happened. Where recovery requires an outcome decision, obtain it from the authorized workflow owner instead of forcing every entry into a completed state.
Verify the next real task, not just the absence of errors
Confirm the next step, assignee, field visibility, and expected notification. A quiet error log is insufficient if the workflow now bypasses a required review. Include a test for the original failing input and another ordinary entry so the repair does not only handle one special fixture.
Document the changed component, tested version, reproduction steps, and evidence of the expected transition. After deployment, monitor the affected path over its normal processing interval. Remove temporary fixtures and debug collection, preserve a redacted incident record, and leave clear instructions for any entries that still require a business decision rather than another technical retry.
Illustrative diagnostic example, not customer measurements.When to bring in help
Ask for WordPress PHP and workflow troubleshooting when a pending entry has no actionable step or a fatal error interrupts client work. Bring a redacted reproduction package and the owner of any custom hooks. Avoid repeated live retries while the execution boundary is unknown.
Related troubleshooting
Inspect a webhook-related PHP failure separately.
Helpful references
Gravity Flow troubleshooting. WordPress debugging.