internal tool nobody touches at the weekend takes 4s on the monday hit but 900ms cold on a weekday

You have two cold starts stacked and you are measuring their sum. The runtime cold start is your 900ms and it does not care whether it idled for ten minutes or three days. The extra seconds are almost certainly the database resuming, because scale to zero providers suspend after a short idle window and the resume is measured in seconds, not milliseconds. Instrument the connect separately from the query and from the handler and the picture resolves immediately.

if you do want it fixed cheaply, one scheduled job at eight on monday morning that opens a connection and runs select 1. costs nothing, runs once a week, and the first human of the week gets a warm path.

i timed this on ours by wrapping four phases with timestamps: process init, module imports, first db connect, first query. on a monday the connect was 2.8s of a 3.9s request and everything else was unchanged from a weekday. thirty minutes of instrumenting saved a week of guessing at bundle size.

for an internal tool with 200 requests a day, consider not fixing it. a loading state that says waking up costs you an hour and the alternative is paying for something to stay running all weekend for one slow request on monday.

worth ruling out the other candidate before you settle on the database. after a long idle your deployment artifact can fall out of whatever regional cache it was in, so the platform fetches and unpacks it again rather than reusing a warm copy nearby. that also shows up as a first hit that is worse than a normal cold start and it looks identical from the outside if you only measure total duration.

i solved this the wrong way first. added a cron to ping the function every few minutes, which kept the function warm all weekend and made no difference at all on monday morning, because the ping did not touch the database. the warmer has to exercise the slow dependency or it is just burning invocations.