Alerts and Runbook

Below is a practical minimum for managed SPG99 operations. These signals help you quickly understand whether the issue is local to one database or affects the platform chain itself.

What is useful to alert on

1. A database in error

This is the main signal that the resource is already outside normal operation.

2. Long booting or an unusually slow cold start

Useful when a sleeping database consistently reaches ready more slowly than expected.

3. scale_state=FAILED

This is an important new signal: writer handoff did not complete.

4. Long FREEZING or DRAINING

This usually means the workload is not allowing cutover to complete safely.

5. Connection and TLS errors

Especially important for Gateway and the client entry point.

6. Growth in pinned/session-heavy traffic

Useful when you suspect that the autoscaler is blocked not by the platform, but by application behavior.

What to do first

1. Open the database card and look at state.
2. Check scale_state, current_profile, and target_profile.
3. Look at Metrics and Logs.
4. If the problem is related to the first connection after idle, verify that connect_timeout is not too small.
5. If the issue affects several databases at once, look at Gateway and the Control Plane as the shared layer.

What to include in a support request

A good escalation package usually contains:

• the tenant and database name;
• the time of the issue;
• the driver or API error text;
• state and scale_state;
• current_profile / target_profile, if relevant;
• a short log fragment;
• a description of what you were doing before the failure.

Practical conclusion

The best runbook for an SPG99 user is first to determine whether the problem is:

• one database;
• cold start;
• autoscale handoff;
• connectivity through Gateway;
• or the entire environment at once.

After that, the path to a solution is usually much shorter.