# SteadyNode — Technical Reference SteadyNode performs outside-in HTTP and API monitoring, isolated browser checks, deployment correlation, and security posture analysis. Use request evidence and application telemetry together; an external check narrows a fault domain but does not prove root cause. ## Core platform capabilities ### Synthetic and HTTP monitoring Schedule outside-in HTTP and browser checks for public services and customer journeys. Documentation: https://steadynode.io/features/synthetic-monitoring - The five-phase socket waterfall records DNS lookup, TCP connection, TLS handshake, time to first byte, and content transfer separately. - HTTP checks validate status and expected response content. Use isolated Playwright journeys for rendered pages and interactions. ### API uptime monitoring Monitor API availability, expected responses, and request timing. Documentation: https://steadynode.io/features/api-uptime-monitoring - Compare network phases over time to distinguish DNS, connection, TLS, and origin-response delays. - Prefer safe read-only routes or an isolated test environment; do not let monitoring change customer data. ### Zero-config JSON Schema Guard Learn successful JSON response structure and flag breaking drift. Documentation: https://steadynode.io/features/api-schema-drift-monitoring - A bounded, value-free Jackson JSON AST extractor keeps field paths and types, not response values. It caps depth at 8, object fields at 200, and sampled array elements at 5. - The canonical structural schema is fingerprinted with SHA-256. The guard reports removed keys, type changes, unexpected nulls, and emptied arrays. - The public comparison tool returns structural metadata only; it does not return submitted JSON values. ### API discovery and OpenAPI import Suggest health and sitemap paths or import eligible static GET routes from OpenAPI documents. Documentation: https://steadynode.io/features/api-discovery-and-openapi-import - Swagger 2.0 and OpenAPI 3.x documents can provide static GET operations for review before monitors are created. - Parameterized paths and non-GET operations are skipped by the static route importer. ### Playwright self-healing Review selector-repair proposals verified inside an isolated Playwright sandbox. Documentation: https://steadynode.io/features/self-healing-browser-tests - A selector-healing snapshot is collected only after a locator timeout on a main document with HTTP 2xx. - The sanitized interactive DOM is capped at 20,000 characters. Input values are omitted, but selected attributes and short text may still contain sensitive data; use test data. - A candidate selector is tested in the isolated sandbox and returned as a diff. Automatic application stays off unless enabled for that journey. ### Deployment blast-radius correlation Place nearby deployments beside failed checks and latency changes during incident investigation. Documentation: https://steadynode.io/features/deployment-correlation - Correlate affected checks, request timings, deployment changes, and changed files to narrow likely fault domains. - Timing and file correlation are evidence for investigation, not proof that a deployment caused an incident. ### Security posture and SBOM radar Track security headers, exposure findings, SBOM inventory, OSV advisories, and CISA KEV matches. Documentation: https://steadynode.io/ - CI/CD can submit CycloneDX SBOMs or supported package manifests for dependency auditing against OSV.dev and the local CISA Known Exploited Vulnerabilities catalog. - The local CISA KEV catalog is synchronized every 12 hours. SBOM findings complement passive runtime and exposure checks. ## Public developer tools and REST APIs The following unauthenticated endpoints back the three interactive developer tools. Send only public test data. The CDN decoder accepts status and response headers; remove credentials and cookies before sending headers. Website security scans use authenticated monitoring routes, not a public developer-tool endpoint. ### TLS Chain Debugger Tool page: https://steadynode.io/tools/tls-chain-debugger Inspects a public HTTPS hostname on port 443. Supply a hostname without a path or query. Request: `GET /api/public/tools/tls-chain` ```sh curl --fail-with-body --silent --show-error --get \ --data-urlencode 'domain=example.com' \ 'https://api.steadynode.io/api/public/tools/tls-chain' ``` ### JSON Schema Comparator Tool page: https://steadynode.io/tools/json-schema-comparator Compares two JSON strings and returns structural differences only. Each document is limited to 1,000,000 UTF-8 bytes. Request: `POST /api/public/tools/json-diff` ```sh curl --fail-with-body --silent --show-error \ -H 'Content-Type: application/json' \ --data '{"baseJson":"{\"order\":{\"id\":123,\"status\":\"paid\"}}","newJson":"{\"order\":{\"id\":\"123\",\"status\":\"paid\"}}"}' \ 'https://api.steadynode.io/api/public/tools/json-diff' ``` ### CDN Error Decoder Tool page: https://steadynode.io/tools/cdn-error-decoder Diagnoses an HTTP status and response headers. Do not send authorization, cookie, or other secret headers. Request: `POST /api/public/tools/cdn-decode` ```sh curl --fail-with-body --silent --show-error \ -H 'Content-Type: application/json' \ --data '{"statusCode":522,"headers":{"server":"cloudflare","cf-ray":"example-ray-id"}}' \ 'https://api.steadynode.io/api/public/tools/cdn-decode' ``` ## CDN and gateway error reference Error signatures vary by provider. Use the status, provider headers, and request identifiers together with origin and edge logs. | Provider | Status | Signature | Likely cause | | --- | ---: | --- | --- | | Cloudflare | 520 | CF-520 | Cloudflare reached the origin, but the origin returned an empty, unknown, or unexpected HTTP response. Next step: Check origin application logs for the request time, verify the origin returns a complete HTTP response, and review firewall or proxy rules that may close the connection early. | | Cloudflare | 521 | CF-521 | The origin web server refused Cloudflare's TCP connection, often because the service is down or a firewall blocks Cloudflare addresses. Next step: Confirm the origin is listening on the configured port, inspect firewall and security-group rules, and allow the published Cloudflare egress ranges where appropriate. | | Cloudflare | 522 | CF-522 | Cloudflare timed out while establishing a connection to your origin server. Next step: Check origin availability and network routes, review firewall allowlists and connection limits, and compare the reported Ray ID with origin-side logs. | | Cloudflare | 523 | CF-523 | Cloudflare could not route a request to the configured origin address. Next step: Verify the origin IP address in DNS and Cloudflare settings, check routing and provider status, and confirm the origin is reachable from the public network. | | Cloudflare | 524 | CF-524 | Cloudflare connected to the origin, but the origin did not send an HTTP response before the response timeout. Next step: Trace the request through application and database logs, optimize slow work, and move long-running tasks to a background job or asynchronous workflow. | | Cloudflare | 525 | CF-525 | Cloudflare could not complete a TLS handshake with the origin server. Next step: Check the origin certificate and supported TLS versions, confirm the origin serves the right certificate for SNI, and inspect handshake errors in origin logs. | | Cloudflare | 526 | CF-526 | Cloudflare Full (strict) mode rejected the certificate presented by the origin as invalid. Next step: Verify the certificate is current, matches the origin hostname, chains to a trusted authority, and includes every required intermediate certificate. | | Cloudflare | 530 | CF-530 | Cloudflare could not resolve or route to the configured origin hostname; HTTP 530 commonly accompanies an Origin DNS Error. Next step: Verify the origin hostname and its public DNS records, check nameserver delegation, and confirm the resolved address is reachable from outside your network. | | Vercel | 504 | VERCEL-FUNCTION_INVOCATION_TIMEOUT | A Vercel function or upstream request exceeded its execution time limit before producing a response. Next step: Inspect function logs and traces, reduce synchronous work, optimize external calls, and move durable long-running work into a background processing system. | | Netlify | 504 | NETLIFY-FUNCTION_TIMEOUT | A Netlify Function or one of its upstream dependencies did not complete before the request deadline. Next step: Inspect function logs using the Netlify request ID, optimize database and external calls, and move long-running work to a background function or asynchronous job. | | AWS CloudFront | 502 | AWS_CLOUDFRONT_502 | The CloudFront origin returned an invalid or incomplete response, or CloudFront could not complete its connection to the origin. Next step: Inspect origin logs, verify the origin protocol and TLS certificate, and confirm the response is valid HTTP with headers that meet CloudFront limits. | | AWS CloudFront | 504 | AWS_CLOUDFRONT_504 | CloudFront did not receive a timely response from the origin or could not establish a connection before its timeout. Next step: Measure origin latency, review connection and response timeout settings, check network reachability, and shorten or asynchronously process long requests. | | Heroku | 503 | HEROKU-H12 | Heroku's router stopped waiting because the dyno did not return a response within the H12 request-timeout window. Next step: Correlate the request ID with router and application logs, optimize slow database or external calls, and move long-running work to an asynchronous job. | | Nginx | 502 | NGINX-502 | Nginx could not obtain a valid response from its configured upstream service. Next step: Check upstream health and listening sockets, inspect Nginx and application error logs, and verify proxy protocol and TLS settings. | | Nginx | 504 | NGINX-504 | The upstream service did not respond to Nginx before its configured gateway timeout. Next step: Trace the request through application and dependency logs, reduce slow synchronous work, and tune proxy timeouts only when the longer request is expected. | ## TLS chain troubleshooting A valid leaf certificate is not sufficient when a client cannot build a chain to a trusted root. SteadyNode inspects the certificates presented by the server and compares the chain with its local trust store; it does not fill a missing issuer from a browser cache. | TLS finding | Meaning | Checks | | --- | --- | --- | | Missing intermediate certificate | The missing intermediate issuer is between the leaf certificate and a trusted root. | Serve the leaf and required intermediate certificates in issuer order. Recheck from a clean JVM or container without a cached intermediate. | | `PKIX path building failed` | A Java client could not build a trusted path from the presented certificate to an issuer in its trust store. | Compare the presented chain with the JVM trust store, verify issuer relationships and validity dates, and test with the same runtime as the failing client. | | Hostname mismatch | The requested hostname does not match a Subject Alternative Name in the certificate. | Inspect the requested host and certificate SANs. Serve a certificate that covers the exact hostname. | | TLS handshake failure | The client and server did not complete TLS negotiation. | Check SNI, supported TLS versions, cipher compatibility, server logs, and the reported handshake failure. | | Expired or not-yet-valid certificate | The certificate validity window does not include the current time. | Check `validFrom` and `validUntil`, host clock accuracy, and certificate renewal and deployment. | | OCSP stapling | The scan reports whether the server stapled an OCSP response; this does not prove the certificate is unrevoked. | Review the certificate authority's revocation status separately and confirm the server's stapling configuration. | | CAA records | CAA DNS records state which certificate authorities may issue for a domain. | Review the returned CAA values and confirm they allow the intended certificate authority. | ## Framework monitoring guides ### Spring Boot Monitor readiness, API contracts, and customer journeys in Spring Boot services. Guide: https://steadynode.io/solutions/spring-boot - Check `/actuator/health/readiness` and business-critical REST routes; keep sensitive Actuator endpoints private. - Use the five-phase waterfall to separate network and TLS delays from time to first byte. Confirm suspected JVM or database causes with application telemetry. - Watch JSON DTO and Java record structure for removed fields, type changes, and unexpected nulls. ### Next.js 16 App Router Check server-rendered routes, hydrated browser flows, API routes, and deployment regressions. Guide: https://steadynode.io/solutions/nextjs-app-router - Pair HTTP route checks with isolated Playwright journeys that assert rendered DOM, client transitions, and form submissions. - An HTTP 200 shell may still contain a broken streamed or hydrated state; assert a customer-visible result. - Use deployment changes and request timing as investigation clues, not proof of causation. ### Node.js Monitor Node.js API timing, JSON contracts, protected APIs, and customer journeys. Guide: https://steadynode.io/solutions/nodejs - A blocked event loop can raise time to first byte while DNS and TCP stay flat; use application telemetry to separate CPU work from downstream I/O. - After a schema baseline is locked, monitor for missing keys, changed types, nulls, and empty arrays. - Use short-lived chained authentication for protected checks and keep detailed dependency data behind access controls. ## Security and dependency posture Outside-in checks assess supported security headers, public exposure signatures, TLS posture, and email-domain configuration. CI/CD SBOM uploads provide dependency inventory for OSV.dev advisory checks and correlation with the locally synchronized CISA KEV catalog. These monitoring workflows are distinct from the unauthenticated developer tools listed above. ## Competitor comparisons - [Pingdom comparison](https://steadynode.io/alternatives/pingdom): Compare endpoint monitoring, API contracts, and browser journeys. - [Datadog Synthetics comparison](https://steadynode.io/alternatives/datadog-synthetics): Compare synthetic monitoring workflows and production diagnostics. - [UptimeRobot comparison](https://steadynode.io/alternatives/uptimerobot): Compare uptime checks, API diagnostics, and incident context.