Close the ticket on the first reply, not the fifth

Most “can’t reproduce” is a stack mismatch. Rebuild their exact versions, make the bug happen, reply with a live URL.

Start free See the toolkit

No credit card · 2 free reproductions at once

ticket #4821

Jamie M. Customer 9:14 AM

Gallery is broken since I updated. WordPress 6.7, PHP 8.1.

Riza Support 9:18 AM

Got it — standing up 6.7 on PHP 8.1 now.

Internal note

Riza Support 9:27 AM

@engineer Reproduced. 6.7 / PHP 8.1 / gallery-block 2.4.1.

ticket-4821.sandywp.com magic login

Trusted by

“Can’t reproduce” is the most expensive two words in support

the thread you’ve had a hundred times

Six days, twelve messages, no reproduction

“It doesn’t work.” No version, no URL, no steps.
You ask for the PHP version. A day passes.
It works on your laptop. Engineering closes it “cannot reproduce”.
Three more customers reopen it under new titles.

with their stack in front of you

One reply, and a URL anyone can open

The ticket says WordPress 6.7, PHP 8.1.
A sandbox on those versions, their plugins preinstalled.
The fatal lands in debug.log while they’re still online.
Engineering opens the broken install, not your description.

From “it doesn’t work” to a URL engineering can open, in four moves

Take three facts off the ticket

WordPress version, PHP version, plugin version.

Build their stack, not your laptop’s

Pick the versions, name the plugins.

Make it break on purpose

Debug mode on, follow their steps, watch debug.log.

Hand over the sandbox, not a paragraph

Drop in the URL and a magic login.

Reproduce it on their stack, not yours

You’re on 7.0.3 and PHP 8.3. They’re on 6.7, PHP 8.1, and three plugins you’ve never run together.

PHP 8.1 surfaces the deprecation that never fires on 8.3
Their plugin set, preinstalled in the same create
Memory down to 64 MB, execution down to 10 seconds

create sandbox

WordPress version

latest 7.0.37.1-RC1 pre-release7.0.3 7.0 6.9 6.8 6.7 6.6

PHP version

7.4 8.1 8.2 8.3 default

Preinstall plugins

woocommercecontact-form-7wordpress-seoclassic-editorelementorwp-super-cache + up to 10 per create

Every combination above is one create form away.

Everything a reproduction needs, and nothing to maintain

version match

Run the version they are stuck on

WordPress 6.6 to 7.0.3 and 7.1-RC1, on PHP 7.4, 8.1, 8.2 or 8.3.

debug mode

See the stack trace, not the white screen

One toggle for all four WP_DEBUG constants. Query Monitor optional.

magic login

Let engineering in without minting credentials

One-click link into wp-admin. No password in the ticket.

Attach the bug, not a description of it

A real install on a public URL. Everyone sees the same break.

lifespan

Keep it standing until the ticket closes

1 hour to 1 month, or permanent on a paid plan.

disposable

Nothing to garden between tickets

Delete it or let it expire. No staging box to maintain.

Say “this is fixed” because you watched it get fixed

The weakest reply in support is “this should be fixed in the next release.”

Deploy the fix branch or release tag from your connected repo
Or attach the ZIP to an @SandyWP Slack mention
Same sandbox, same data — only the build changed

Deploying builds needs the CLI, Git deployment or Slack — paid plans.

$ sandywp deploy ticket-4821 gallery-block-2.4.2-rc1.zip

✓ uploaded gallery-block-2.4.2-rc1.zip

✓ installed and activated on ticket-4821

$ sandywp ssh ticket-4821

www-data@sandywp:/var/www/html$

$ wp plugin list --status=active

gallery-block 2.4.2-rc1 active

$ tail -f wp-content/debug.log

— steps repeated, no new entries

Hand engineering something they can open, not a paragraph they have to believe

WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY and SCRIPT_DEBUG, from one toggle
tail -f wp-content/debug.log over SSH for the raw stream
Query Monitor when it’s queries, not PHP

What debug mode turns on →

Debug log

wp-content/debug.log · 3 entries · updated just now

Fatal error 10:11:31

Uncaught TypeError: call_user_func_array(): invalid callback, class "Adsglue_Admin" not found in /wp-includes/class-wp-hook.php:341

Stack trace: #0 WP_Hook→apply_filters() · #1 WP_Hook→do_action()

Warning 10:11:36

Undefined array key "columns" in /wp-content/plugins/gallery-block/includes/render.php on line 217

Warning 10:11:37

Trying to access array offset on value of type null in /wp-content/plugins/gallery-block/includes/images.php on line 84

database

Read the row instead of guessing at it

Full database admin in the browser, one click.

files

Open render.php at the line the log named

Browser file tree and code editor. No FTP.

shell

Drop to a shell when the UI runs out

SSH into the sandbox’s own container, wp-cli preinstalled. Paid plans.

reset

Start clean when you stop trusting it

Reset to a known-good install.

When it only breaks on their site, work on a copy of their site

Some bugs live in the data: a 90,000-row options table, a theme somebody forked in 2019.

1 The customer installs SandyWP Cloner, the free wordpress.org plugin.
2 One click copies the database and wp-content into a fresh sandbox.
3 It runs in the background — chunked and resumable.
4 You get a private copy of their site to break.

How the Cloner works →

customer production

customersite.com

database · wp-content · media

read only

reproduction sandbox

ticket-4821.sandywp.com

their data · your debug flags

break freely

Production is only ever read.

Nothing is written back, modified or deleted. Say that in your reply.

Build the reproduction once, then relaunch it every time that ticket comes back

Save any sandbox — versions, plugins, theme, content, database — as a template
Launch a fresh, isolated copy when that ticket lands again
One template per recurring bug: a library a new hire inherits

How templates work →

saved reproductions

woo + object cache

WordPress 6.7 · PHP 8.1 · 4 plugins

reopened 6× launch

php 8.1 deprecations

WordPress 7.0.3 · PHP 8.1 · debug on

reopened 4× launch

multisite subdirectory

WordPress 6.9 · PHP 8.3 · 3 sites

reopened 3× launch

big import · 40k rows

WordPress 7.0 · PHP 8.2 · 512 MB

reopened 2× launch

Each launch is a separate sandbox.

Answer the release-week ticket wave before the release ships

Preinstall the plugins your customers pair you with, and find the conflict first
Upload a plugin ZIP up to 50 MB to test an unreleased build
Beta sandboxes provision cold, so allow a few extra seconds

Test against the next release →

The three weeks around a major

Today

Spin 7.1-RC1 and find the fatal before anyone’s waiting.
19 August 2026

WordPress 7.1 ships. Your fix is already released.
The week after

The tickets arrive anyway — each one gets an answer, not an investigation.

7.1-RC1pre-release latest7.0.3 back to 6.6

The rest of what’s in the box

Priced by how many broken sites you keep standing, not per seat

Free

$0forever

2 reproductions open at once

256 MB storage
1-week lifespan, 12-hour retention
Debug mode, log viewer, file manager, database manager, magic login

No credit card.

Plus

$7per month

10 reproductions open at once

5 GB storage
Permanent sandboxes, 7-day retention
SSH, CLI, Slack, Git deployment, PHP config

$70/year, two months free.

Pro

$17per month

25 reproductions open at once

15 GB storage
Permanent sandboxes, 7-day retention
SSH, CLI, Slack, Git deployment, PHP config

$170/year, two months free.

Best value

Max

$27per month

50 reproductions open at once

30 GB storage
Permanent sandboxes, 7-day retention
SSH, CLI, Slack, Git deployment, PHP config

$270/year, two months free.

No team seats today — you share a reproduction by sharing its URL. SandyWP vs InstaWP →

What support teams ask

How fast is a reproduction sandbox actually ready?

About 30 seconds. The 7.1-RC1 track provisions cold, so allow a few more.

Does the customer need a SandyWP account to open what I send them?

No. Sandbox URLs are public and magic login skips the password; launch links give guests one sandbox at a time, 7-hour lifespan.

Does cloning a customer’s site touch their live site?

No. The Cloner only reads: it copies the database and wp-content out, and writes nothing back.

How long does a reproduction live, and what happens when it expires?

1 hour to 1 month or permanent; 1 week by default. Retention: 6 hours for guests, 12 on Free, 7 days on paid.

Can I pin a sandbox open until the ticket closes?

Yes, at create time or later. Permanent, 2-week and 1-month lifespans are paid.

Which WordPress and PHP versions can I match?

WordPress 6.6, 6.7, 6.8, 6.9, 7.0, 7.0.3, latest and 7.1-RC1, on PHP 7.4, 8.1, 8.2 or 8.3 (8.3 default).

Can I test against the next WordPress release before it ships?

Yes — 7.1-RC1 is on the create form. WordPress 7.1 is due 19 August 2026.

Can I reproduce a plugin conflict, not just one plugin?

Up to 10 wordpress.org plugins per create, installed and activated. Themes too, up to 5.

What if the bug only shows up under a tight resource limit?

Nine php.ini values per sandbox: memory 64–512 MB, execution 10–300s, upload and post size. Restart takes 5–10 seconds.

Do I need SSH or the CLI to work this way?

No. Debug toggles, log viewer, file manager, database manager and reset are on every plan. SSH, CLI, Slack and Git deployment are paid.

Is one customer’s reproduction isolated from another’s?

Each sandbox is its own container. SSH lands inside it, never the host or another tenant — key-based and off by default.

Does this plug into my helpdesk, and can my whole team share an account?

No to both: no Zendesk, Intercom or Help Scout app, and no team seats. Slack is the one native integration.

Answer the next ticket with a URL, not a question.

Free to start, no credit card.

Start free Read the docs