Registers one or more healthcheck endpoints on a Shiny app by decorating the app object's
internal HTTP handler. Requests matching a registered path (via GET) are answered by
handler before any UI rendering, session creation, or authentication occurs; all other
requests fall through to the app unchanged.
Because the interception happens on the app object's own handler, no uiPattern
adjustment is required and the endpoint works regardless of how the app was constructed
(plain shiny::shinyApp(), golem, UI wrappers, etc.).
Registrations stack: call add_healthcheck() multiple times with different paths to expose
e.g. separate liveness and readiness
endpoints (/livez, /readyz) with their own handlers.
Usage
add_healthcheck(
app,
path = "/health",
handler = health_handler_default,
verbose = shiny::in_devmode()
)Arguments
- app
A shiny application object, typically created using
shiny::shinyApp().- path
Character vector of URL paths to register (each must begin with
/). Default"/health".- handler
A healthcheck handler: a function of
reqreturning ahealth_response(), ashiny::httpResponse(), or a named list. Seehealth_handler_default()for the full contract. Errors thrown by the handler are converted into a503"fail" response.- verbose
Logical; log a console message for each healthcheck request received. Evaluated once at registration time. Defaults to
shiny::in_devmode().
Value
The modified app object, classed c("shinyhealth_app", "shiny.appobj"), with registration
metadata stored in the shinyhealth attribute.
Examples
app <- shiny::shinyApp(
ui = shiny::fluidPage("hello"),
server = function(input, output, session) {}
)
app <- add_healthcheck(app)
has_healthcheck(app)
#> [1] TRUE
healthcheck_paths(app)
#> [1] "/health"
# stack a second endpoint with a custom handler
app <- add_healthcheck(app, path = "/readyz", handler = function(req) {
health_response(checks = list(database = list(status = "pass")))
})
healthcheck_paths(app)
#> [1] "/health" "/readyz"
