Changes and propagation

A successful write acknowledges a change to saved configuration. It does not mean the change is active at every edge location. Read back the configuration, then check the behavior you changed.

Note: Balancer is in beta. Endpoints, fields and behavior may change before general availability, and the feature must be enabled on your account before use. Contact your NetActuate account manager to request access.

What success establishes

Configuration publication and application are asynchronous. Different requests can encounter different applied revisions during propagation. Some write handlers acknowledge the operation before the transaction finishes, so readback is also needed to confirm the saved state.

One configuration polling path defaults to 10 seconds, with a configurable minimum of 1 second and a server-controlled next delay. This is not a propagation deadline. Other publication and validation steps also affect activation. No fixed end-to-end activation time is established.

Check each feature

Feature	Check saved state	Check active behavior
HTTP load balancers, groups, domains and routes	Read domain and route assignments, priority and expressions.	Request the intended domain with the intended method, path, scheme and TLS server name.
Upstream groups and health checks	Read origin settings, probe Host, path, port and TLS settings.	Send a controlled site request; compare origin behavior and health observations with support.
Block policies, allow policies and custom lists	Read list contents, policy assignment and effective route mode.	Send a controlled request that exercises the policy.
WAF firewalls, rulesets and WAF allow policies	Read effective assignments, mode and validation state.	Compare matched-rule observations for the same controlled request and the request fields used by expressions.
Rate limits	Read inheritance, priority, expression, bucket inputs and validation state.	Compare request attribution and the configured limit behavior.
Cache policies and purge	Read effective assignment, validation and purge scope.	Compare repeated requests with origin logs and cache observations. Sampled log absence alone does not establish a cache hit.
Error pages	Read rule scope, status match, asset content type and disabled state.	Reproduce a matching error and compare the returned status and body.
Image manipulation	Read policy and variant settings.	Compare image diagnostics with the returned image body; variant identity and cached copies affect observations.
HTTP protection	Read the applicable configuration.	Record request identifier, UTC time, HTTP status and challenge outcome. Ask support which protection produced the response.
DNS	Read zone records.	Compare authoritative answers, then recursive answers after the previous TTL. No authoritative publication deadline is established.
TLS certificates and certificate issuance	Read certificate status and dnsChallenge; check the published challenge TXT record.	Inspect the certificate served by the actual site. Issuance also depends on DNS and the certificate authority.
Mutual TLS	Read the selected certificate and client authentication settings.	Check the actual TLS handshake with the intended client credentials.
Logs and export	Read effective accessLogsEnabled and export destination.	Find a controlled request in a bounded query window and at the destination. Event time and delivery time differ.
Credentials and permissions	Read effective membership and grants.	Test the exact API operation with the intended credential and context. No edge polling interval applies.
Limits	Read the setting for the affected feature.	Use that feature's verification method. There is no universal activation time.

L4 creation operations currently reject requests as unavailable. Where an existing L4 configuration can be inspected, verify the listener protocol and port, the TLS handshake when applicable, and an application exchange. Ask support to confirm application of the relevant serving configuration. No bounded rollout time is established.

Verify an HTTP change

Use a load balancer with an existing domain and route. Set BALANCER_API_BASE to https://<your-api-host>, using the host shown in the Balancer portal, and set BALANCER_HTTP_LB_ID to your resource identifier.

1. Read back the desired configuration.

   curl --silent --show-error \
     "$BALANCER_API_BASE/http-loadbalancers/$BALANCER_HTTP_LB_ID" \
     -H "x-api-key: $BALANCER_API_KEY"

   Expect HTTP 200 with data containing the load balancer and groups. Compare it with your intended settings. Read the affected nested resource when its settings are not included here.

2. Send a controlled request to your configured domain. Replace example.com with that domain.

   curl --silent --show-error -i 'https://example.com/'

   Expect the status, headers and body required by your configured route and policies. Compare this result with the specific change. A successful API read alone does not verify activation.

3. If behavior differs, record the request identifier when available, UTC time and observed response. Ask support to compare the saved and applied revisions for the serving configuration. A timeout alone does not establish an invalid configuration.

TODO(verify): Confirm customer-visible activation indicators and upper propagation bounds for each feature.