# GatewayLabs Full Context GatewayLabs is one release-to-incident decision product for small DevOps, SRE, platform, and backend teams. The paid product has two connected workflows. ConfigDiff and Signal remain technical compatibility names, not separately sold products. Specfold is a separate desktop developer tool: - Release Check uses the ConfigDiff engine before deployment to compare configuration and environment state against known-good baselines. - Incident Answer uses the Signal module during an incident to connect application evidence, Elastic/OpenSearch state, Windows/Linux resource signals, recent changes, and suggested first checks. - Specfold by GatewayLabs turns messy OpenAPI, Swagger, Postman, Insomnia, HAR, HTTP, and cURL inputs into clean editable local-first API collections with scoped gateway routing, focused HTTP request testing including safe multipart form-data uploads, and OpenAPI YAML/JSON or `specfold.collection.v1` exports. Incident Answer does not call an external AI/LLM provider. Its customer result remains deterministic. Model assistance is limited to GatewayLabs-trained, versioned artifacts after corpus, evaluation, parity, offline, and pilot gates pass. ## GatewayLabs Workflows ### Release Check (ConfigDiff engine) Release Check is used before release or during post-release verification. Its ConfigDiff engine compares JSON, YAML, XML, INI, TOML, plain text, appsettings, web.config, environment variables, and other operational configuration sources. Typical workflows include release readiness, Azure DevOps pipeline checks, scheduled drift monitoring, sensitive key masking, policy-based review, and support handoff reports. Release Check is most useful when: - A team has repeated environment-specific issues. - Staging, UAT, and production can drift apart. - Release owners need a repeatable review instead of manual file scanning. - A known-good baseline can be pinned after a healthy release. - Sensitive differences must be masked while still showing risk. ### Incident Answer (Signal module) Incident Answer is used after release when production symptoms appear. Its Signal module helps teams connect application and API gateway errors, upstream service logs, exception patterns, Elastic/OpenSearch health, Windows/Linux CPU, memory and disk pressure, Azure DevOps deploys, Terraform operations, Kubernetes rollout events, and configuration drift. Incident Answer is most useful when: - The team asks "what changed in the last one or two hours?" - Runtime errors are noisy and repeated. - The first useful log source or query is not obvious. - Recent deploy, config, infrastructure, and runtime evidence live in different systems. - A safe incident report is needed without exposing raw production logs. Incident Answer can start with a safe sample, manual paste, or upload for a single incident. Connected agents and restricted-network workflows can be added after the team proves value with one incident. ### Specfold Specfold by GatewayLabs is a lightweight local-first desktop companion for Windows, macOS, and Linux. It is not positioned as a broad protocol testing suite. It imports OpenAPI 3.x, Swagger 2.0, Postman v2/v3, Insomnia v4/v5, HAR 1.2, `.http`/`.rest`, Collection JSON, or curl commands; cleans messy specs, gateway exports, and captured requests into independently collapsible collections and nested folders; resolves inherited environment-, collection-, and folder-scoped base URLs with a visible source; supports folder-scoped access tokens whose values remain encrypted environment secrets; places the request editor above a resizable response inspector; provides persistent A-/A+ response text sizing, adjustable text density, request templates, and safe multipart form-data file upload testing; sends focused HTTP requests from the desktop app; exports OpenAPI or Specfold Collection JSON with clipboard copy; exposes About, documentation, and manual update checks through native desktop menus; and can back up, restore, or delete the complete local workspace. The current public release is v1.9.0. Published installers, packages, and SHA-256 checksums are served from GitHub Releases: https://github.com/Gatewaylabsnet/specfold/releases/tag/v1.9.0 Reference: https://gatewaylabs.net/specfold ## Authenticated Studio user guide The public Studio guide is at https://gatewaylabs.net/docs/studio. It gives signed-in users a task-first choice: use Incident Answer for a live incident or Release Check for a release setting check. It covers workspace boundaries; Viewer, Editor, Admin, and PlatformAdmin roles; plan requirements; both safe first workflows; automation setup; team settings; billing; and security boundaries. Specfold remains a separate local desktop companion. Billing changes are reviewed in Studio by an Admin. Before payment, the workspace owner must separately verify the Paddle checkout purchaser, plan, billing interval, price, currency, and taxes; choosing a plan in Studio is not confirmation of payment. ## Optional Fixed-Scope Incident Review GatewayLabs offers the Signal Incident Clarity Sprint as a one-time professional service. The commercial flow is: - Free fit check: 20 minutes around one real or production-like incident. - Paid fixed-scope Sprint: USD 299 globally or TRY 9,900 in Turkey; applicable taxes are shown before payment. - Start condition: written scope approval, 50% booking deposit, and acceptance of the safe input package. - Target delivery: two business days after the start condition is met; the balance is due before the final report is released. - Scope: one incident, up to three source categories, up to two sanitized snippets, one report, one 30-minute readout, and one consolidated correction round. - Output: incident timeline, source map, suggested searches, recent change correlation, missing telemetry fields, and a Signal fit assessment. - Boundary: no SaaS subscription or automatic renewal is included. Results are limited to supplied evidence; automatic or certain root cause, remediation, and time savings are not guaranteed. The review is intentionally not an open-ended monitoring project. Recurring GatewayLabs software plans are optional and billed separately after proof. ## Blog and Field Notes GatewayLabs publishes short field notes that bridge product pages and technical guides. These pages are useful when a reader needs a practical incident or release workflow before opening the full docs. ### Restricted-network incident pilot readiness checklist Use this note when a team needs to validate Signal safely before sharing production data. The checklist covers the First Incident Wizard, hosted demo data, hybrid read-only collection, offline evidence packs, starter profiles, analysis, handoff reports, and pilot pass/fail output. Reference: https://gatewaylabs.net/blog/restricted-network-incident-pilot-readiness ### What the first 15 minutes of an incident should produce Use this note when a team needs a realistic incident triage target. The first 15 minutes should produce a source ranking, one or two useful queries, a recent-change timeline, and a safe handoff note. It does not need to prove the full root cause. Reference: https://gatewaylabs.net/blog/first-15-minutes-incident-clarity ### Offline incident evidence packs for restricted networks Use this note when raw production logs, credentials, and private endpoints must stay inside the restricted network. The recommended workflow is local collection, normalized evidence, explicit export, and a short operator-ready report. Reference: https://gatewaylabs.net/blog/offline-incident-evidence-pack ### Azure DevOps deploy regression timeline Use this note when an incident may be related to a recent Azure DevOps release. The useful timeline joins pipeline run, artifact version, commit, work item, approver, config drift, Terraform, Kubernetes, and runtime evidence. Reference: https://gatewaylabs.net/blog/azure-devops-deploy-regression-timeline ### Config drift before release checklist Use this note when a small team wants repeatable release readiness checks. The workflow is known-good baseline, candidate snapshot, sensitive key masking, policy-aware comparison, and an explicit release decision. Reference: https://gatewaylabs.net/blog/config-drift-before-release-checklist ### API gateway 503 runbook template Use this note when the first responder needs a short runbook for gateway 503s. The template captures impact, first source, first query, recent change, and handoff without pretending the root cause is already known. Reference: https://gatewaylabs.net/blog/api-gateway-503-runbook-template ### Nexus package pull build failure Use this note when build pipelines fail on package restore, Nexus, proxy auth, registry, dependency pull, cache, or timeout patterns. The useful first split is access versus availability. Reference: https://gatewaylabs.net/blog/nexus-package-pull-build-failure ### Private-network Signal agent checklist Use this note for restricted-network rollouts. The checklist covers scoped Signal tokens, read-only local checks, local alert output, redaction, public key download, offline bundles, and local evidence JSON. Reference: https://gatewaylabs.net/blog/private-network-signal-agent-checklist ### Azure DevOps config drift release gate Use this note when .NET or IIS teams want ConfigDiff inside Azure DevOps before release. The gate should mask secrets, classify high-risk keys, publish a report, and feed meaningful drift into Signal after release. Reference: https://gatewaylabs.net/blog/azure-devops-config-drift-release-gate ## Important Technical Guides ### API gateway 503 and timeout triage Use this workflow when an API gateway returns 503, upstream timeout, connection reset, or route-specific failures. A gateway status code alone is not enough evidence. Useful triage joins route, upstream service, status, duration, correlation ID, service version, dependency latency, deploy events, config drift, Terraform changes, and Kubernetes rollout events. Recommended first searches: - `status:503 AND route:/checkout AND upstream:orders-api` - `message:(timeout OR upstream_timeout OR connection reset) AND service:orders-api` - `correlationId: OR trace.id:` - `change.source:(azure_devops OR configdiff OR terraform OR kubernetes)` Reference: https://gatewaylabs.net/guides/api-gateway-503-timeout-triage ### Azure DevOps deployment incident timeline Use this workflow when a production incident may be related to a recent Azure DevOps deployment. The core question is what changed in the last one or two hours. A useful timeline joins pipeline runs, commits, work items, approvals, rollback attempts, config diffs, Terraform operations, Kubernetes rollout events, manual operations, and first error spikes. Recommended evidence: - Azure DevOps build or release run ID. - Commit SHA, branch, work item, approver, and artifact version. - ConfigDiff findings for appsettings, web.config, environment variables, and gateway settings. - Signal incident groups, first seen time, last seen time, and source queries. Reference: https://gatewaylabs.net/guides/azure-devops-deployment-incident-timeline ### Elasticsearch and OpenSearch incident triage Use this workflow when application errors may be caused by Elastic or OpenSearch pressure. App-facing timeout noise should be checked against cluster health, unassigned shards, disk watermarks, data path partitions, JVM pressure, query latency, indexing pressure, CPU, memory, and service status. Recommended first searches: - `message:(ElasticsearchTimeoutException OR OpenSearch timeout)` - `dependency:(elasticsearch OR opensearch) AND durationMs:>3000` - `cluster.status:(yellow OR red) OR unassigned_shards:>0` - `disk.percent:>85 AND path:/var/lib/elasticsearch` Reference: https://gatewaylabs.net/guides/elasticsearch-opensearch-incident-triage ### Kubernetes rollout 503 debugging Use this workflow when a 503 appears after a Kubernetes rollout. Check whether the error starts at ingress, gateway, service mesh, or the app. Then join deployment rollout history, image tag, replica readiness, pod restarts, service endpoints, readiness probe failures, ConfigMap changes, Secret references, ingress changes, and Terraform changes. Recommended first searches: - `kubernetes.namespace:prod AND kubernetes.deployment.name:` - `ingress.status:503 AND upstream:` - `event.reason:(Unhealthy OR FailedScheduling OR FailedMount)` - `pod.version: AND message:(timeout OR connection refused)` Reference: https://gatewaylabs.net/guides/kubernetes-rollout-503-debugging ### Config drift monitoring for Azure DevOps Use this workflow before release. Pin a known-good production baseline after a healthy release, compare staging or UAT before the next deployment, mark expected differences, mask sensitive keys, and publish the report into Azure DevOps release review. Recommended checks: - `ConnectionStrings.*` changed outside approved release. - `FeatureFlags.*` differs between UAT and production. - `UpstreamTimeoutSeconds` changed before a 503 spike. - `Auth.Authority` or JWT settings differ between environments. Reference: https://gatewaylabs.net/guides/config-drift-monitoring-azure-devops ### Incident Clarity Sprint Use this one-time professional service to validate the Incident Answer workflow without a large procurement or integration project. Pick one incident, identify the first sources the team checks, convert the first one or two queries into presets, map recent deploy, config, infrastructure, and runtime evidence, and deliver a short report. Reference: https://gatewaylabs.net/guides/incident-clarity-pilot ### ConfigDiff vs manual config review Manual review is useful for human judgment but weak at repeatability. ConfigDiff is useful when the same high-risk configuration checks must happen before every release. The best workflow combines automated detection with human approval for expected differences. Reference: https://gatewaylabs.net/compare/configdiff-vs-manual-config-review ## Canonical URLs - Home: https://gatewaylabs.net/ - Specfold: https://gatewaylabs.net/specfold - Signal: https://gatewaylabs.net/signal - Pricing: https://gatewaylabs.net/pricing - Demo: https://gatewaylabs.net/demo - Blog: https://gatewaylabs.net/blog - Docs: https://gatewaylabs.net/docs - ConfigDiff docs: https://gatewaylabs.net/docs/configdiff - Signal docs: https://gatewaylabs.net/docs/signal - Specfold docs: https://gatewaylabs.net/docs/specfold - Sitemap: https://gatewaylabs.net/sitemap.xml - Short LLM index: https://gatewaylabs.net/llms.txt ## Contact Contact GatewayLabs at orkun@gatewaylabs.net for an Incident Answer fit check, Release Check rollout, or GatewayLabs product inquiry.