SLA
This is why reading and understanding the Service Level Agreement (SLA) for any service you intend to rely upon is a Very Good Idea. As Galileo is still in the "Initial Open Service", it is not intended for 'primetime' use. Despite that, lots of people are using it anyway, assuming that availability now means it will continue to be available in the future. It's very kind of them to act as testing guinea-pigs.
Lots of companies sign up for SLAs with telecomms service providers, cloud services, IT service providers and the like without fully understanding the SLAs buried deep within the contracts.
I have met some 'interesting' SLAs in my time. How about 'guaranteed service restoration within 48 hours of an outage'? So when things failed at 16:00 on Friday, you'd expect service back by 16:00 on Sunday? Well, it turned out that the outage clock only ticked during 'normal working hours', deemed to be 09:00-17:00 Mon-Fr, so 48 hours after 16:00 on Friday was...16:00 on the Monday after the next weekend - a whole working week and a day after the outage actually occurred. Of course, those signing the contract thought they would get service back at latest 48 real-time hours later.
Another fun SLA was an availability SLA which defined how availability would be measured. The contract stated that a particular procedure would be used, which happened to be the same as the procedure used to demonstrate a service was working before acceptance. Which sounds good. There were two problems with this: firstly, the test procedure could only be carried out while the service was not in production use; and secondly the SLA specified an annual availability, which could only be measured (according to the contract) by having the service run the acceptance procedure for a year.
The conclusion is that contractual SLAs should be read very, very carefully, and you should make sure that you and the supplier have a common understanding of the SLA. Which is horribly boring, and means that you should probably give up on assuming 'good faith', because high performance levels usually require lots of money and resources, which suppliers are loath to give away cheaply.
The current (issued in May 2019) Service Description for Galileo is here: EUROPEAN GNSS (GALILEO) : OPEN SERVICE DEFINITION DOCUMENT. Section 3 goes into detail on the Minimum Performance Levels (MPLs) of the service, with section 3.4.4 specifically describing the availability of the Galileo positioning service*: which, summarised, is greater than or equal to 70% calculated over a period of 30 days at the worst user location.
With my jaded experienced eye, I can see that averaging availability over 30 days is the usual trick for making a service provider's life easier. As a service user, you want the averaging period for a service's availability to be as short as possible - so if you are billed monthly, you, as a user, want the availability to exceed the agreed level averaged over (say) a rolling 24 hour period, and if it drops below the target in any 24 hour period during the billing cycle, the target for the cycle is not met. Or if 24 hours is too long, a rolling hourly period. Suppliers really don't like that.
So, yes, the Galileo SLA has been carefully written to mean that Galileo has a very good chance of meeting its targets. Depending on your point of view, this either means that the SLA writers in Galileo were on the ball, or that they are deliberately massaging the figures (in advance, remember, this was published in May 2019) to make themselves look good. Read the next version of the Galileo Open Service Definition document carefully.
*Note, the MPL for the Galileo UTC Time Dissemination service is better than or equal to 87%, calculated over a period of 30 days. It failed to meet its target in July (see pages 12 and 13 of the report), reaching only 81.7%
The MPL of 87%9specified by [OS-SDD] for the long term is therefore not achieved in July, while it is in August and September. This is again a side effect of the occurred incident (ref.:Annex A).
[OSS-SDD] European GNSS (Galileo) Open Service Definition Document (OS-SDD), Issue 1.1, European Union, May 2019.
Issue 1.1 of the [OS-SDD] is in force since May 2019. This version is accessible for download from the European GNSS Service Centre (GSC) website.