Why Power Cut Notices In India Are So Hard To Understand

Power cut notices in India are difficult to understand. They will tell you the exact time of the power cut, but you will still be unable to figure out whether it applies to you or not.

If you ask why, the answer is that the shutdown names a feeder and not the name of your street or your colony. The electricity board knows its meaning, but you, sitting at home, won’t be able to figure out whether to charge the inverter before or after lunch.

Honestly, that’s a real gap in public outage information. Anyone can go to Google and search the page easily, where they can actually find the information about the power cuts. The challenge lies in understanding the content of that page. A maintenance issue is not a complaint record. A complaint record does not prove that power is back.

I will talk about two examples here: Punjab’s PSPCL and Telangana’s TGSPDCL. Their official pages contain different sorts of records, and I’d argue that looking closely at those records tells you more about how to fix power outage information than any grand plan for a complete national picture of electricity supply ever will.

Begin by understanding what kind of record is in front of you

So if you want to know about the upcoming maintenance schedules, you will find the shutdown records, then you squint at them and try to figure out whether the mentioned feeder has anything to do with your address or not.

The data you will find on the page will not promise that every interruption record is mentioned there. It will not work like that.

The PSPCL outage source overview identifies the planned shutdown source and also describes its scope.

It’s useful and good for comparing how different utilities publish data. This will only show you evidence about a particular date, a particular place, or a particular work window. You need to check the actual notice.

TGSPDCL’s Power Outage grievance abstract report is a completely different document. It lumps open grievances together by electricity circle and by reporting the same on the channel app, website, phone, or control room.

When you open it, you will see a reporting window and an option to update the time. The labels on the page are doing real work. This is a report about the complaints within a defined scope.

The TGSPDCL outage source notes will keep track of the scheduled information, and the grievance source is exactly the separation needed to compare utilities.

So here’s the real trap: a complaint report will tell you what people have reported, and it will not tell you how many faults exist. It certainly will not tell you how many homes are in the dark right now.

You think about this: if five people are complaining about the same outage, the complaint will sit there marked as “open” for days even after the lights come back.

That’s why converting the complaint total into “number of faults” is just making things up, and the source doesn’t support this. If you summarize it, carry the original label through.
Your locality name is not a feeder name.

What people really do is enter the name of their neighborhood, or that of their village, or their PIN code address. The distribution records actually include circles, divisions, substations, and feeders, all of which have completely different boundaries.

It would require actual evidence to match one onto the other, particularly when you are going to inform someone that their house will lose power.

It would be wrong to suppose that a postal area is based on a single feeder. If a source does give a feeder but says nothing about the localities, you should honestly leave the feeder name in and acknowledge that the location has limitations.

Each mapping involving a feeder and a locality must have a source and a review history attached to it.

If you omit that, a faulty translation will be embedded and will reappear every time a new notice comes in. Although no one notices it, it will continue to replicate.

People can contribute in this situation by indicating any missing names or incorrect matches. You must regard their reports as leads and not as definite facts. Someone has to compare the report with the utility information and record the reason for the change in mapping.

Read the time carefully as you read the place

Well, imagine that you have a maintenance notice specifying that the work window is from 10 a.m. to 1 p.m. (this is purely an example and not a real shutdown).

Before you arrange the entire day around that notice, you should first check the date of the notice, then see which area is affected, and also verify if a more recent notice has altered the timings, since a notice from yesterday with the correct place name refers to tomorrow.

As for 1 p.m., that is merely the time by which the work is expected to be completed. It is not the time when the lights actually came back on. Therefore, if the crew is late and your screen still says ‘restored: 1 p.m.’, then you are being shown false precision, and people will believe it without questioning.

Unplanned outages are even more complicated. Let’s say that the power has been off for two hours before anyone makes a complaint.

In that case, the time of the complaint is not the real beginning of the outage, since it merely represents the moment when someone became annoyed enough to file the complaint.

The acknowledgement, the estimated time of restoration, and the confirmed time of restoration all have different meanings, and they ought to continue to have different meanings.

The same reasoning holds true when it comes to fetching and updating. For example, suppose a collector obtained the utility report at 11 a.m., but the utility last published any data at 8 a.m.

If you only display the time of collection, the reader has no means of knowing that the data underneath is already three hours out of date. Therefore, if the source provides you with both times, include both of them. It’s not at all difficult.

If the search comes back empty, there needs to be a reason why

The search produces no results, which is all right, but why is that? Maybe there is no planned shutdown in that area.

It could be that the notice assigned a different name to the location. Or the source may not have been updated. It might also be the result of an unexpected fault, something that wasn’t included in the schedule you were looking for in the first place.

The honest answer about “No planned notice meeting the criteria was located in this source at this time.” Although such an answer is indeed useful, as long as one understands the scope of it, it in no circumstances acts as evidence that your electricity supply is operational.

If a lookup fails, it must be given a completely different message: in the case of a timeout, it should state that the source is unavailable, because the reader cannot see behind the scenes and has no knowledge of the collection process existing, and so the interface has to draw that line for them. If the server were broken, it would silently turn into a false assurance about someone’s power supply.

Testing has this same problem. The fact that a webpage loads successfully tells us almost nothing. Are the expected fields still gotten through?

Have the dates been interpreted correctly? Has someone changed the table layout last week and simply broken your data extraction without anyone having noticed? A report that returns zero matching records and one that is completely unreadable should not give the same response.

What a useful public notice would contain

At least the affected area, the date, the intended work window, and the current status. It also helps if there is a reason given for the work, since this enables people to more easily forgive an outage when they understand it.

Moreover, a stable identifier should be used so that when the time changes, the same event is updated rather than appearing to result in a second shutdown.

Make sure that the original source remains accessible. If your summary has reduced a long list of affected areas, provide people with a way to access the full notice.

Likewise, if you have used any abbreviations that are not familiar, include a link to the full notice. This applies also to cases where the locality matches are uncertain.

Utilities could also provide a machine-readable version together with the human-readable one. This could be in the form of CSV, JSON, or something similar. In that way, other services will be able to access the actual fields rather than having to reverse-engineer a layout that changes every few months. Those people who merely want to quickly look at their area can still see the readable version.
For unplanned events, separate fields should be provided for the reported or detected start time, acknowledgement, and restoration information where this is available.

If the time is unknown, leave it blank and write ‘unknown ‘. Do not fill the blank with any timestamp that is nearby, since that would make the record appear to be complete while in fact altering what is actually stated.

To make it clear, these are proposals. I am not saying that either of the two utilities currently publishes all of the fields mentioned here. A shared format would be worthwhile exactly since the underlying records vary so much in their purpose and in the amount of detail.

Keep revisions and watch the gaps

An archive must store the original notice together with all subsequent changes, including any cancellations. Thus, if a schedule that was shown at breakfast is no longer valid by lunch, a reader can discover the reason. Moreover, errors in the summaries can then be traced rather than remaining mysterious.

However, don’t go too far in claiming this as evidence of reliability. An archive of notices isn’t a reliability index. Some planned work does finish early, while at other times it finishes late. Without further analysis, open complaints don’t indicate how many separate outages there actually were.

If you rank the utilities solely on the basis of these records, you’re essentially ranking them on the quality of their paperwork rather than their service.

Community observations can provide actual information since they include their own labels. A resident who writes “power’s back” is not giving an official restoration update. Any duplicates or contradictions have to be checked before anyone draws any conclusions based on them.

Is it a sensible first move? Perhaps a small pilot study covering a number of clearly specified sources. Does it pick up the notices?

Do the locality matches in fact verify? Have the revisions been reached to the readers in time? And whoever is in charge of it must have a permanent procedure for detecting faulty sources and for dealing with corrections, or the scheme will die within a year. Such things always do.

The main issue is this: do not mask the gaps by putting up a confident-looking status label. Instead, let people know which notice you’ve looked at, state how old it is, and inform them whether it applies to their address or not. All of this can be done without any new infrastructure, since the records already exist. They’re just there in a form that no one can use. By fixing that situation, people will then be able to actually plan their day around a power cut notice rather than just ignoring it.