$ sprite checkpoint list -s …
Error: failed to list checkpoints: failed to make request: Get “https://api.sprites.dev/v1/sprites/…/checkpoints”: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
this is happening for some commands, like checkpoint listing, but working for another sprite that’s located on the same FRA region.
Same experience (not sure where my sprite is, though).
the location might be wrong. i’m going on the assumption that the response header fly-request-id is suffixed by the region string.
Too late for this incident, but it would be nice if there were external backup/restore for checkpoints.
That’s your location actually (the client making the HTTP request). Your request gets routed first to the nearest Fly.io edge node (which is what that suffix shows) and then onward within the internal network to the Sprite or organization-wide metadata node, etc., which could be arbitrarily far away.
With normal Machines, you can set flyio-debug: doit as a request header and get back a JSON blob, in the response header, which includes information about the actual Machine that ultimately did serve the request. Look in the sr and sdc fields in particular. I’m not 100% sure those are still valid for Sprites, but it’s probably a better indicator…
i had a sprite with a bunch of checkpoints suddenly report no checkpoints at all, so i am not trusting that feature anymore. once i have something that i care about it goes into git and i try to push often.
i really like the idea of the sprites service, but it seems to be more of a side project than something one can trust to be there when needed.
just noticed the response is now a 500 error:
Error: failed to list checkpoints: API returned status 500: Failed to list checkpoints: overlay manager not configured
Flicking the status page back to “Operational” without checking for other damage does make it seem like that 
Got out my credit card and filed a P0. I’ll keep you updated.
From support:
“Thanks for writing in about this! It looks like there was an error on this Sprite and I’ve reset it.”
It’s working for me now.
they probably saw mine in there too because the sprite is back online.
how much did you have to pay for the support ticket?
I had to get the Premium plan, which I thought was going to be $200 but since it happens to be at the end of the month was prorated to $15.
My Sprite got wedged two more times yesterday. (Quick fixes from support, though.)
you can definitely use flyio-debug header for sprites 
nixie:~$ curl https://meow2-ibym.sprites.app -H flyio-debug:doit -I
HTTP/2 501
content-length: 357
content-type: text/html;charset=utf-8
date: Wed, 01 Apr 2026 12:41:37 GMT
server: Fly/dea3e0cdc (2026-03-30)
sprite-version: v0.0.1-rc31
via: 2 fly.io, 2 fly.io
fly-request-id: 01KN4H0JF51HQC9MCYWM23BMMH-ams
flyio-debug: {"n":"edge-cf-ams1-7a5c","nr":"ams","ra":"redacted","rf":"Verbatim","sr":"fra","sdc":"fra2","sid":"2861632bee55e8","st":0,"nrtt":0,"bn":null,"mhn":"worker-cf-fra2-2373","mrtt":6}
in this case my closest region is ams and my sprite machine is in fra.
i’m seeing them again now, and what’s concerning me the most is that when i cannot open a console to the sprite it won’t take http calls either.
i absolutely love sprites, but the qos makes me want to move away from using them.
do you have any tips on actions one can take to keep the sprite “healthy”. i have this sprite i need to have available from other sprites, it hosts an app where agents can post/get text blobs. it holds some “knowledge” i like to transfer around. it’s really annoying to pass the link to another sprite and have claude lose cycles because it can’t connect to the other sprite.
a few feature requests for the sprite service:
can you take a look at top on one of those sprites you have issues connecting to?
i just noticed that mine had many zsh, npm, and claude processes. zsh was in the dozens.