Every developer knows the moment. Something that worked yesterday doesn't work today. A page that was fast is slow. A request that used to return 200 now returns 500. Your mind immediately fills with questions, and none of them are about writing code:
Which route got slower? When did it start? Which commit did it? If I replay the request, will it even fail the same way again? And can I look at my colleague's branch without wrecking my own setup to do it?
Grove has always been the web server for your local sites, so it sees every request. 1.10 is about using that position to answer those questions. Every one of these answers comes with a promise we kept throughout: your checkout and your database are never touched.
The problem. A page feels slow, or a test run takes longer, but "slow" is a feeling. Some requests are slow anyway, for boring reasons. The database was starting up, OPcache was recompiling, or the machine was busy. If you chase every slow request you'll never get anything done, and if you ignore them you won't notice the N+1 query until production.
Grove times every request PHP answers and keeps the times per route. A route is the method plus the path, with ids, UUIDs, ULIDs and long hashes folded into placeholders, so /orders/17 and /orders/18 are the same route:
$ grove routes
SITE ROUTE SEEN TYPICAL RECENT
shop GET /orders/{id} 26 21ms 222ms slower 10.6× for 0s, e.g. request #66
shop GET / 20 21ms 21ms
The design is all about not crying wolf.
Typical is the median of the route's last 50 requests. Recent is the median of its last five. Both are medians, so one slow request moves nothing. A cold database start or an OPcache recompile won't raise an alarm.
A route is flagged only when recent is at least twice typical and at least 50 ms more, and only once it has ten requests behind it.
While a route is flagged, its baseline stops taking samples. Otherwise a regression would quietly become the new normal after a few dozen requests, and the flag would clear itself without anything being fixed. The flag clears when the route is actually fast again. If the new speed is deliberate, --reset accepts it.
Only answers below 400 count, because how fast an error comes back tells you nothing about the route. Static files don't count at all.
We tested it on a route that went from 21 ms to 222 ms. It was flagged on the third slow request, and the baseline stayed at 21 ms through fifty more.
And here's what it doesn't catch, stated as plainly as the changelog states it: a slowdown that creeps in a few percent at a time is absorbed into the baseline and never flagged. grove routes is for the route that jumps, the N+1 query or the dropped index. It isn't a profiler, and it doesn't pretend to be one.
The problem. A request that used to work now returns 500, and you have forty commits between "worked" and "doesn't". git bisect is the right tool, but running it on a web app by hand is miserable. You check out a commit, run composer install, migrate a database, reload the page, and mark good or bad. Then you do it again, while your own work is stashed and your database has been migrated back and forth through forty schemas.
Now you give Grove a commit where the request worked, plus one of the requests it recorded:
$ grove bisect --good 3f2a9c0 --request 1
COMMIT STATUS SUBJECT
59f8d721a3 500 bad c8: notes
aba631d973 200 good c4: more notes
fcb901b823 500 bad c6: rename total to amount in the report
b540fc73ef 200 good c5: report sums invoice totals
first bad commit: fcb901b823 c6: rename total to amount in the report
For each step, Grove checks the commit out beside your checkout, at shop--bisect.test. It gives that copy a fresh copy of your database migrated to that commit, runs composer install only if composer.lock changed, and replays the recorded request with its method, path, headers and body. git bisect does the narrowing. Your checkout never moves, and neither does your database.
Two small details show how carefully this was built. First, Grove checks that the request really does fail at the "bad" end before it starts, so you don't bisect towards nothing. Second, it waits three seconds per step, because at two seconds OPcache was still answering with the previous commit's code. The answer is only useful if every step tests the commit it says it tests.
The problem. Grove has been able to replay a recorded request since the beginning, and it's a wonderful debugging loop: replay, read the error, fix, replay. Except when the request writes. The second time you replay "create order", the order already exists. The third time you replay "sign up", the email is taken. By the fourth time, you're debugging the side effects of your own replays.
$ grove replay 1 --same-data
baseline taken of MySQL `shop`; later --same-data replays start from it
replayed → 200 in 1ms
$ grove replay 1 --same-data
MySQL `shop` put back to the baseline first
replayed → 200 in 1ms
The first --same-data replay takes a snapshot of the site's database, and every later one puts it back before sending the request. Now you can change the code and try the exact same request from the exact same starting point as many times as you need. On MySQL and SQLite, three replays of a POST that inserts a row left one row more than the baseline, not three.
One honest detail: the starting point is your data at that first --same-data replay, not at the moment the original request was made. For a failed request that rolled back, those are the same. If the original request did write something, undo it once before you start.
The problem. A colleague asks you to look at their branch. Reviewing it properly, meaning actually clicking through it, used to cost you: stash your work, check out their branch, composer install, npm install, migrate your database into their schema, look around, then undo all of it and hope your data survived.
$ grove try feature/invoices
Now their branch runs beside yours, at myapp--feature-invoices.test. It's in its own worktree, on its own copy of your database, with your .env copied and the hostname replaced everywhere it appears. vendor, node_modules and public/build are cloned copy-on-write, so it takes seconds and uses no extra disk. composer install only catches up with the differences in their lock file, and their migrations run on their copy.
You can click around their feature in one tab and keep working on yours in the next. Both have real data, and neither touches the other.
It's careful about cleanup too. A try whose setup fails part-way is undone completely, so there's no half-made worktree left over. grove try … --done refuses while the worktree holds uncommitted work, and names the files. (And if you wondered why the name has a double hyphen: every subdomain of a site already routes to that site, so myapp-feature could collide and myapp--feature can't.)
The same machinery that powers try powers something for AI agents. With grove mcp --allow-write, an agent can get a sandbox: a complete running copy of a site on a new branch, in its own worktree, with its own migrated copy of the database and its own HTTPS address. Every other Grove tool can then be pointed at that sandbox by name.
What this means in practice: you can let an agent run migrations, seed data and hit the app, and your checkout and your database are never involved. When it's done, closing the sandbox keeps the branch with the agent's commits, so you review them like any other branch. Closing refuses while anything is uncommitted, and names the files.
An agent also gets grove_routes, so it can check whether its own change made a route slower before telling you it's finished.
These tools only exist with --allow-write. A read-only grove mcp never offers them.
1.9 introduced on-demand databases, which run only while something is connected. The first query after a database had gone idle took about 0.35 s, because the server was starting behind it.
1.10 starts it earlier. A browser resolves myapp.test before it connects, often while you're still typing the address, and Grove answers that DNS lookup by starting the site's idle databases in the background. With a lookup 0.4 seconds ahead, the first request after MySQL had gone idle took 43 ms instead of 354. That's the same as if MySQL had been running all along. You get the memory saving without having to wait for it.
Look at the features again:
grove routes tells you which route broke.
grove bisect tells you which commit broke it.
--same-data lets you retry the fix against the same starting point, as many times as it takes.
grove try and agent sandboxes let you, or an agent, run code you haven't adopted yet, beside the code you have.
They only work because Grove already owns the web server and the database. It sees every request, times every route, and can snapshot, copy, migrate and put back a database without asking you for a connection string. And each tool keeps the promise we care about most in a development tool: it works beside what you're doing, never on it. Your checkout and your database are never touched.
Grove 1.10.0 is at elyracode.com/grove, for macOS on Apple silicon and Intel, and Linux as AppImage, deb and rpm. The daemon and the CLI use the same protocol as 1.9.0, so there's nothing to do but update.
Then try it on the route you've been meaning to look at:
grove routes
grove bisect --good <a commit from last week> --request <the one that fails>
And the next time a colleague says "can you take a look at my branch?", say yes without stashing anything.