WSUS Console returns HTTP 503 after SUSDB reaches 10 GB limit

Yes. The supported order is to clean up WSUS content and metadata first, then shrink and reindex the database. Shrinking before cleanup usually provides little benefit.

Recommended manual procedure:

1. Disable scheduled synchronizations
   • Disable any scheduled syncs in Configuration Manager or on the standalone WSUS server before maintenance.
   • If WSUS is in a hierarchy, run cleanup on each WSUS server starting at the lowest level.
2. Back up SUSDB
   • Back up the WSUS database before making changes.
3. Run the SQL script for slow spDeleteUpdate performance
   • This is the first step in the documented manual maintenance sequence.
4. Reindex and update statistics
   • Rebuild indexes:

      EXEC sp_MSforeachtable @command1="SET QUOTED_IDENTIFIER ON;ALTER INDEX ALL ON ? REBUILD;"
   

   • Update statistics:

      Exec sp_msforeachtable "UPDATE STATISTICS ? WITH FULLSCAN, COLUMNS"
   

   • Microsoft also provides a dedicated WSUS reindex T-SQL script for SUSDB maintenance.
5. Clean synchronization history
   • If the console is unstable or crashes, cleaning sync history is part of the documented manual process:

      USE SUSDB 
      GO 
      DELETE FROM tbEventInstance WHERE EventNamespaceID = '2' AND EVENTID IN ('381', '382', '384', '386', '387', '389')
   

6. Decline superseded updates and clean obsolete updates
   • Clean up superseded updates older than the configured retention period.
   • Clean up obsolete updates.
   • In Configuration Manager environments, the supersedence period should match the SUP supersedence rules.
   • If the number of superseded, declined, and obsolete updates is high, these cleanup steps may need to be repeated multiple times.
7. Run WSUS cleanup from elevated PowerShell
   • Start the WSUS Cleanup Wizard from an elevated PowerShell prompt.
   • Then remove declined updates with the documented PowerShell script:

      [reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
      $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
      $wsus.GetUpdates() | Where {$_.IsDeclined -eq $true} | ForEach-Object {$wsus.DeleteUpdate($_.Id.UpdateId.ToString()); Write-Host $_.Title removed }
   

   • Some cleanup steps can take hours, and errors during parts of the cleanup can be expected. Repeat the declined/obsolete cleanup cycle until update counts are reduced.
8. Shrink SUSDB files and then shrink the database
   • After cleanup has removed enough data, shrink the SUSDB files and then shrink the SUSDB database.
   • This is the documented point where shrinking is performed.
9. Reindex and update statistics again
   • After cleanup and shrink operations, reindex and update statistics again for best performance.

Additional guidance for the 10 GB SQL Server Express limit:

• If maintenance takes too long or cannot complete successfully, the documented guidance is to create a new SUSDB.
• If the count of superseded updates is above 1500, it can cause server- and client-side software update issues.
• If the last three columns in the WSUS update-count query exceed a few hundred, maintenance should be performed.

For connecting to SUSDB:

• If SUSDB is on WID and the OS is Windows Server 2012 or later, use \\.\pipe\MICROSOFT##WID\tsql\query in SSMS.
• If SUSDB is on full SQL Server or SQL Server Express, connect to the SQL Server instance name in SSMS.
• If SSMS cannot connect to WID, try launching SSMS with Run as administrator.

So for the specific question: use cleanup and metadata reduction first, then shrink, and include reindex/statistics maintenance before and after the shrink phase.

• Maintain the Windows Server Update Services (WSUS) database manually or automatically
• The complete guide to WSUS and Configuration Manager SUP maintenance
• Reindex the WSUS database