I've noticed that in Atlantis v0.22.3, when we do a deploy, it gets to the point where it logs:

{
  "level": "info",
  "ts": "2023-05-17T20:10:54.823Z",
  "caller": "server/server.go:941",
  "msg": "Atlantis started - listening on port 4141",
  "json": {}
}

However, the web interface won't load and webhooks from GitHub time out. We do see a number of log entries similar to:

{
  "level": "info",
  "ts": "2023-05-17T20:15:38.576Z",
  "caller": "server/server.go:1016",
  "msg": "Apply Lock: {false 0001-01-01 00:00:00 +0000 UTC }",
  "json": {}
}

They seem to occur more often if I attempt to re-load the web interface. But it can sometimes take 10+ minutes after Atlantis claims to have started listening before it is actually in a functional state (still trying to confirm whether my refreshing the web interface is actually causing those Apply Lock log lines and possibly speeding up the launch, as it anecdotally feels that way, almost as if it is working through some queue). We have

disable-repo-locking: true

in our Atlantis config file. We are also using the default

boltdb

(and not doing anything fancy at the moment to persist it across deployments). Curious if anyone else has experienced this and knows how to speed up the slow startup times.

have you checked CPU and Memory saturations?

CPU and Memory are nowhere near its limits (neither at deploy time nor during regular operation), it is absolutely overprovisioned when it comes to resources right now.

there is no reason to be slow on start

To clarify, we've been running with more or less this setup for over a year. So I wasn't intending to call out the localdb. All of the volumes are EBS devices in AWS. There is no nfs or anything like that.We also don't have any persistent volumes associated with Atlantis.

no issues , I'm just curious that it takes time to start

Ours used to as well :)

do you know if there are old PRs in the data dir ?

We don't preserve the data directory across deploys, so it is empty.