Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/CodexaCP/SERVICIOS-BACK/llms.txt

Use this file to discover all available pages before exploring further.

The ServiciosYa API exposes two health endpoints at the root level — outside the /api/v1 prefix and without any authentication requirement. They are designed for use by container orchestrators, load balancers, and uptime monitors to determine whether the process is running and whether it is ready to serve traffic. Neither endpoint is gated by the EnableDiagnostics flag; they are always available regardless of configuration.
These endpoints do not require an Authorization header. They are intentionally public so that infrastructure probes can reach them without credentials.

​
GET /health/live — Liveness probe

The liveness endpoint is a minimal signal that the process is alive. It performs no I/O and always responds 200 OK as long as the ASP.NET Core request pipeline is running. Use it to tell your orchestrator when a pod or container should be restarted. Authentication: None
Method: GET
Path: /health/live

​
Response — 200 OK

{
  "status": "OK",
  "timestampUtc": "2026-05-01T12:00:00Z"
}
​
status
string
Always "OK". This value never changes — the endpoint only returns when the process is responsive.
​
timestampUtc
string (ISO 8601)
The current UTC timestamp at the moment the response was generated.

​
Example

curl -i https://api.serviciosya.com/health/live

HTTP/1.1 200 OK
Content-Type: application/json

{"status":"OK","timestampUtc":"2026-05-01T12:00:00Z"}

​
GET /health/ready — Readiness probe

The readiness endpoint performs two active checks before responding: it opens a SQL Server connection and executes SELECT 1 to verify database reachability, and it writes and deletes a small temporary file under wwwroot/uploads to confirm filesystem access. The overall status reflects the worst result across both components. Use this endpoint to tell your orchestrator when a pod should start receiving traffic. Authentication: None
Method: GET
Path: /health/ready

​
Response — 200 OK (all components healthy)

{
  "status": "OK",
  "timestampUtc": "2026-05-01T12:00:00Z",
  "components": [
    { "name": "sqlserver", "status": "OK",    "message": "Conexion SQL disponible." },
    { "name": "storage",   "status": "OK",    "message": "Acceso a almacenamiento disponible." }
  ]
}

​
Response — 503 Service Unavailable (one or more components unhealthy)

{
  "status": "Error",
  "timestampUtc": "2026-05-01T12:00:00Z",
  "components": [
    { "name": "sqlserver", "status": "Error", "message": "No se pudo verificar SQL Server." },
    { "name": "storage",   "status": "OK",    "message": "Acceso a almacenamiento disponible." }
  ]
}
​
status
string
Aggregate status of all components. Possible values:
ValueMeaning
OKAll components are healthy.
WarningAt least one component degraded but none errored.
ErrorAt least one component returned an error.
​
timestampUtc
string (ISO 8601)
UTC timestamp when the check was executed.
​
components
array
List of individual component check results.
​
components[].name
string
Component identifier. Currently "sqlserver" and "storage".
​
components[].status
string
Per-component status: "OK" or "Error".
​
components[].message
string
Human-readable diagnostic message in Spanish describing the outcome.

​
Example

# Healthy
curl -i https://api.serviciosya.com/health/ready

# Unhealthy — SQL Server unreachable
# HTTP 503 is returned; inspect "components" to identify which check failed
curl -s https://api.serviciosya.com/health/ready | jq '.components'

​
Kubernetes / Docker configuration

Configure /health/ready as the readiness probe and /health/live as the liveness probe. This way Kubernetes will stop routing traffic to a pod that cannot reach the database (readiness failure) without restarting a pod that is merely waiting for DB connectivity to recover (liveness still passing).
livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 15
  failureThreshold: 3
Unlike the /api/v1/system/* diagnostics endpoints, the health endpoints are never disabled by the Diagnostics:EnableDiagnostics configuration flag. They are always reachable.

Build docs developers (and LLMs) love

Get started for freeTalk to us