# GatewayLabs Full Context GatewayLabs is a release safety and incident clarity platform for small DevOps, SRE, platform, and backend teams. The platform has two connected release-safety products and one standalone desktop developer tool: - ConfigDiff prevents release risk before deployment by comparing configuration and environment state against known-good baselines. - Signal explains runtime failures after deployment by correlating logs, recent changes, infrastructure operations, and suggested search patterns. - 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. ## Products ### ConfigDiff ConfigDiff is used before release or during post-release verification. It 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. ConfigDiff 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. ### Signal Signal is used after release when production symptoms appear. It helps teams connect API gateway errors, upstream service logs, exception patterns, Elastic/OpenSearch health, Azure DevOps deploys, Terraform operations, Kubernetes rollout events, and configuration drift. Signal 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. Signal can start with 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 a task-first path for signed-in users: use Signal for a live incident, ConfigDiff for a release setting check, and Specfold for local API requests. It covers workspace boundaries; Viewer, Editor, Admin, and PlatformAdmin roles; plan requirements; safe first Signal and ConfigDiff workflows; Studio environment profiles versus local Specfold environments; automation setup; team settings; billing; and security boundaries. 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. ## Fixed-Scope Signal Sprint 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 Sprint is intentionally not an open-ended monitoring project. Recurring Core, Team, Business, and Enterprise 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 Signal 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 Signal Sprint fit checks, ConfigDiff rollout questions, or GatewayLabs platform inquiries.